summaryrefslogtreecommitdiff
path: root/cf/f3012203124a9a7710c1515409982bfcbf9834
blob: 2914afdf867a41a29670b6bb2c48bd6d5166b65a (plain)
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
Return-Path: <staf@stafverhaegen.be>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 44C2C40C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Feb 2017 15:33:32 +0000 (UTC)
X-Greylist: delayed 00:06:40 by SQLgrey-1.7.6
Received: from lvps83-169-4-30.dedicated.hosteurope.de
	(lvps83-169-4-30.dedicated.hosteurope.de [83.169.4.30])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D933216A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Feb 2017 15:33:30 +0000 (UTC)
Received: (qmail 15908 invoked from network); 11 Feb 2017 16:26:47 +0100
Received: from unknown (HELO hpdc7800) (10.0.0.1)
	by 10.0.0.2 with (AES128-SHA encrypted) SMTP; 11 Feb 2017 16:26:40 +0100
Message-ID: <1486826793.21100.114.camel@stafverhaegen.be>
From: Staf Verhaegen <staf@stafverhaegen.be>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Sat, 11 Feb 2017 16:26:33 +0100
In-Reply-To: <4C206BDC-CCAB-4F4B-9356-6FA7652E467A@voskuil.org>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
	<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
	<201701280403.05558.luke@dashjr.org>
	<CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
	<A6A9E83E-6A5A-4583-A4E3-A52DF33DCF4F@petertodd.org>
	<583ef2d2-8315-da9f-7815-768cb4ccb515@thinlink.com>
	<4C206BDC-CCAB-4F4B-9356-6FA7652E467A@voskuil.org>
Content-Type: multipart/signed; micalg="pgp-sha256";
	protocol="application/pgp-signature"; boundary="=-Pfei/rfCus6mb93ibHpU"
X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) 
Mime-Version: 1.0
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,HELO_DYNAMIC_IPADDR
	autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 11 Feb 2017 16:49:58 +0000
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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: Sat, 11 Feb 2017 15:33:32 -0000


--=-Pfei/rfCus6mb93ibHpU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Eric Voskuil via bitcoin-dev schreef op zo 29-01-2017 om 11:37 [-0800]:
> > On Jan 29, 2017, at 11:15 AM, Tom Harding via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
> >=20
> >> On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote:
> >> a world of nodes in large datacenters is a world where it's very easy
> >> to force the few Bitcoin nodes remaining to follow AML/KYC rules
> >=20
> > If that's true, why haven't we already seen AML/KYC required of mining
> > pools?  That would be comparatively trivial.
>=20
> It is true, there is no question. The fact that an attack does not appear=
 to have occurred does not mean that the vulnerability exists. It is as you=
 say a trivial exploit, which means it will happen when the economic incent=
ive is great enough. Analogous attacks on other points of centralization ar=
e already well underway.

What on first sight seems trivial may be totally different when looking
deeper. People here seem to not realise that a lot of data centers (the
IAAS ones) just are just grouping the computers and provide remote
access. The client have full control over the machines. The center thus
just provides the hardware, the power and the internet access. They
typically don't inspect your internet traffic only reduce the speed if
you are going above certain threshold. Additionally there are countries
like Iceland that specifically make laws to not let the government get
power over data and network traffic in data centers.
Domestic ISP services typically want to prioritize traffic and thus have
most of the time network traffic deep packet inspection (DPI)
capabilities. These are thus much easier forced by government to filter
certain traffic. Additionally these companies often fall under
telecommunication laws also given government more control over them than
in a typical data center.

I host my Bitcoin node in a German datacenter and am sure it is more
censorship resistant that a node going through any American ISP.

greets,
Staf.


--=-Pfei/rfCus6mb93ibHpU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EABEIAAYFAlifLS8ACgkQWIjyN0LdGqywvAD/VKnF7s5bTq9x3xlMRyA8PTqk
yalIT5hTRRWEqSssyqQA/1Q2XLsEyiJS7Du2tHlsKucBdckfSfgRtcBvFi6jjp4M
=MpKa
-----END PGP SIGNATURE-----

--=-Pfei/rfCus6mb93ibHpU--