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
|
Return-Path: <PoliceTerror@dyne.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B282589C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 21:31:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from tupac2.dyne.org (tupac2.dyne.org [178.62.188.7])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA8B81CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 21:31:35 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: policeterror@dyne.org)
with ESMTPSA id 270BF1817E4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dyne.org; s=mail;
t=1466717493; bh=NeZlVZRfIOCYKaT7hfkSKfXqRTwWVqPfmemEz/R/Llg=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=t0wgDR2F5kfdloHRyvcRyPfk2Eio4otwyUrn0GRW+QPNCFVDhv690t3Fk/qxYznmG
Xl0aays9/kbkg24ame66f/nUn0PKYjnLNo6WlVNofqoZajdU3fzM5Fqn4YVKYsHy5X
eXm638Dp1K/RrOSVoJegYySJnDsyIhLfAiTbSXO0=
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
<20160621221347.GC10196@fedora-21-dvm>
<CABqynxJCiXL0djx+xt9i=HJqC=0=5sZ9ecL7k1_a_XHiJ8qibw@mail.gmail.com>
<20160623105632.GB19241@fedora-21-dvm>
<ebfa5034-827d-00a6-c285-dab30aa3e9c8@sky-ip.org>
<CABqynx+KGxD3ZwAAcD9VBcO8U13LKC=5kfOhsX32MxdM_hnHxA@mail.gmail.com>
From: Police Terror <PoliceTerror@dyne.org>
Message-ID: <576C5531.90608@dyne.org>
Date: Thu, 23 Jun 2016 21:31:29 +0000
MIME-Version: 1.0
In-Reply-To: <CABqynx+KGxD3ZwAAcD9VBcO8U13LKC=5kfOhsX32MxdM_hnHxA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2016 21:31:36 -0000
In England under RIPA 2000 legislation, it's irrelevant whether you have
the data or not. If the authorities compel you to hand over that
information, and it is within your means to obtain it then you are
obliged to do so under threat of criminal offense.
So any mechanism whereby data could be collected from Bitcoin users,
whether it's stored ephemerally or not, if the police have reasonable
suspicion to think it exists then they can compel all parties to work to
get them the data they require.
If the mechanism flat out does not exist, that is miles better than
could exist. Deniability is not a defense when served with a police
notice for disclosing data.
You have to think not only about the end result, but also about how
these mechanisms can be used for intimidating users or leveraging
technologies.
Justin Newton via bitcoin-dev:
> On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>>
>> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
>> expectations from _all_ users from authorities. Companies or individuals
>> who want and/or need AML/KYC can find ways and do it at their side
>> isolated from the entire network, and the solutions shouldn't come from
>> upstream. AML/KYC/<insert other regulation here> differ from country to
>> country and will be hard to implement in a global consensus network even
>> if it would be worth it.
>>
>>
> This was precisely our thinking as well.
>
> This is actually exactly why BIP 75 was designed the way that it was. Any
> (voluntary) identity exchange is done at the application level, on an
> encrypted https (or other) connection between the sender and receiver.
> Identity data is not passed through or stored on the blockchain, and there
> is actually no mark left on the blockchain that identity was even exchanged
> on that transaction.
>
> The only people who know identity info was exchanged, or what the identity
> was is the counterparties in the transaction, and depending on
> implementation, their service provider. (At a high level, many software
> based wallet providers wouldn’t have any visibility into identity info,
> where many hosted services would, for example)
>
> We did this to protect user privacy as well as fungibility.
>
> We are allowing the people who want or need to exchange identtity info
> (either self signed or 3rd party validated) the option to exchange it, in a
> standards based way, directly between peers, without touching the
> blockchain or network itself.
>
> Is this more clear?
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
