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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1VClHa-00059X-Rc
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Aug 2013 06:55:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=gmaxwell@gmail.com;
helo=mail-la0-f47.google.com;
Received: from mail-la0-f47.google.com ([209.85.215.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VClHX-00052b-CI
for bitcoin-development@lists.sourceforge.net;
Fri, 23 Aug 2013 06:55:42 +0000
Received: by mail-la0-f47.google.com with SMTP id eo20so190831lab.6
for <bitcoin-development@lists.sourceforge.net>;
Thu, 22 Aug 2013 23:55:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.115.176 with SMTP id jp16mr14037930lab.17.1377240932544;
Thu, 22 Aug 2013 23:55:32 -0700 (PDT)
Received: by 10.112.89.72 with HTTP; Thu, 22 Aug 2013 23:55:32 -0700 (PDT)
In-Reply-To: <CAD=_8RR=vm0ivpdNg7=bnX_bQ7CC8oZnVi5iWXvbgeBD8W4Ctg@mail.gmail.com>
References: <CAD=_8RR=vm0ivpdNg7=bnX_bQ7CC8oZnVi5iWXvbgeBD8W4Ctg@mail.gmail.com>
Date: Thu, 22 Aug 2013 23:55:32 -0700
Message-ID: <CAAS2fgT4fJ1ED=yqp+0Ym=Z7n+TjqZ759dSOCSO_3MZEvtLhRw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Maciej Trebacz <maciej@bitalo.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: 1VClHX-00052b-CI
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Way to tell that transaction was issued
by a specific person/company
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: Fri, 23 Aug 2013 06:55:43 -0000
On Thu, Aug 22, 2013 at 11:26 PM, Maciej Trebacz <maciej@bitalo.com> wrote:
> So if you have multiple addresses you can't
> sign them with a single private key and include that signature in the
> transaction so other party can verify it against your public key. This co=
uld
> become very handy though - a reputable wallet service could issue
> transactions that require zero confirmations from the other party, becaus=
e
> with the added signature they know that the transaction is from this
> reputable service and they trust that this service won't try to double
> spend. I'm thinking of something like Mt.Gox's "green address", but baked
> into protocol (Mt.Gox does this by sending your funds to some known by th=
e
> others Bitcoin address and then relaying them to the final destination).
>
> Do you think it's possible/feasible to add a feature like this to the
It's feasible to do such things but I believe highly undesirable.
You're taking data which is inherently only of short term interest to
a single party in the whole world (the receiver) and enlarging the
transaction and increasing the effective transaction fees while
forcing (say) a hundred thousand other parties to spend effort
transmitting it, processing it, and storing it for all time.
While doing so you also leak to the whole world=E2=80=94 who would have
previously had no way or reason to know=E2=80=94 who the identity of one of
the parties in the transaction is in a strong cryptographically
non-reputable way... which then lowers the privacy of everyone in the
transaction graph region of that transaction since some coercive force
could send some ninjas out to bust some kneecaps of the identified
party until they tell them where those coins came from and where they
went. If you observe section 10 of Bitcoin.pdf you can see that
privacy in Bitcoin is based _exclusively_ on using pseudonymous
identities on every transaction. If you break that, you remove privacy
from Bitcoin, leaving it at a competitive disadvantage to centeralized
payment systems, which all provide pretty good basic privacy (against
most criminals and nosy neighbors) as a core feature.
Instead: You can simply perform this transaction using the payment
protocol, which could provide along all sorts of additional metadata
including signatures from the relevant parties. By doing this, only
the parties that need to learn something learn something: privacy is
preserved and bloat is avoided.
If the payment protocol is too heavy handed for you, simply giving the
user a signmessaged txid can show a promise to pay for a transaction
without highly public communication.
|
