1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/'
>
4 <title>Petter Reinholdtsen - Entries tagged usenix
</title>
5 <description>Entries tagged usenix
</description>
6 <link>http://people.skolelinux.org/pere/blog/
</link>
10 <title>A fist full of non-anonymous Bitcoins
</title>
11 <link>http://people.skolelinux.org/pere/blog/A_fist_full_of_non_anonymous_Bitcoins.html
</link>
12 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/A_fist_full_of_non_anonymous_Bitcoins.html
</guid>
13 <pubDate>Wed,
29 Jan
2014 14:
10:
00 +
0100</pubDate>
14 <description><p
>Bitcoin is a incredible use of peer to peer communication and
15 encryption, allowing direct and immediate money transfer without any
16 central control. It is sometimes claimed to be ideal for illegal
17 activity, which I believe is quite a long way from the truth. At least
18 I would not conduct illegal money transfers using a system where the
19 details of every transaction are kept forever. This point is
21 <a href=
"https://www.usenix.org/publications/login
">USENIX ;login:
</a
>
22 from December
2013, in the article
23 "<a href=
"https://www.usenix.org/system/files/login/articles/
03_meiklejohn-online.pdf
">A
24 Fistful of Bitcoins - Characterizing Payments Among Men with No
25 Names
</a
>" by Sarah Meiklejohn, Marjori Pomarole,Grant Jordan, Kirill
26 Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage. They
27 analyse the transaction log in the Bitcoin system, using it to find
28 addresses belong to individuals and organisations and follow the flow
29 of money from both Bitcoin theft and trades on Silk Road to where the
30 money end up. This is how they wrap up their article:
</p
>
32 <p
><blockquote
>
33 <p
>"To demonstrate the usefulness of this type of analysis, we turned
34 our attention to criminal activity. In the Bitcoin economy, criminal
35 activity can appear in a number of forms, such as dealing drugs on
36 Silk Road or simply stealing someone else’s bitcoins. We followed the
37 flow of bitcoins out of Silk Road (in particular, from one notorious
38 address) and from a number of highly publicized thefts to see whether
39 we could track the bitcoins to known services. Although some of the
40 thieves attempted to use sophisticated mixing techniques (or possibly
41 mix services) to obscure the flow of bitcoins, for the most part
42 tracking the bitcoins was quite straightforward, and we ultimately saw
43 large quantities of bitcoins flow to a variety of exchanges directly
44 from the point of theft (or the withdrawal from Silk Road).
</p
>
46 <p
>As acknowledged above, following stolen bitcoins to the point at
47 which they are deposited into an exchange does not in itself identify
48 the thief; however, it does enable further de-anonymization in the
49 case in which certain agencies can determine (through, for example,
50 subpoena power) the real-world owner of the account into which the
51 stolen bitcoins were deposited. Because such exchanges seem to serve
52 as chokepoints into and out of the Bitcoin economy (i.e., there are
53 few alternative ways to cash out), we conclude that using Bitcoin for
54 money laundering or other illicit purposes does not (at least at
55 present) seem to be particularly attractive.
"</p
>
56 </blockquote
><p
>
58 <p
>These researches are not the first to analyse the Bitcoin
59 transaction log. The
2011 paper
60 "<a href=
"http://arxiv.org/abs/
1107.4524">An Analysis of Anonymity in
61 the Bitcoin System
</A
>" by Fergal Reid and Martin Harrigan is
62 summarized like this:
</p
>
64 <p
><blockquote
>
65 "Anonymity in Bitcoin, a peer-to-peer electronic currency system, is a
66 complicated issue. Within the system, users are identified by
67 public-keys only. An attacker wishing to de-anonymize its users will
68 attempt to construct the one-to-many mapping between users and
69 public-keys and associate information external to the system with the
70 users. Bitcoin tries to prevent this attack by storing the mapping of
71 a user to his or her public-keys on that user
's node only and by
72 allowing each user to generate as many public-keys as required. In
73 this chapter we consider the topological structure of two networks
74 derived from Bitcoin
's public transaction history. We show that the
75 two networks have a non-trivial topological structure, provide
76 complementary views of the Bitcoin system and have implications for
77 anonymity. We combine these structures with external information and
78 techniques such as context discovery and flow analysis to investigate
79 an alleged theft of Bitcoins, which, at the time of the theft, had a
80 market value of approximately half a million U.S. dollars.
"
81 </blockquote
></p
>
83 <p
>I hope these references can help kill the urban myth that Bitcoin
84 is anonymous. It isn
't really a good fit for illegal activites. Use
85 cash if you need to stay anonymous, at least until regular DNA
86 sampling of notes and coins become the norm. :)
</p
>
88 <p
>As usual, if you use Bitcoin and want to show your support of my
89 activities, please send Bitcoin donations to my address
90 <b
><a href=
"bitcoin:
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
&label=PetterReinholdtsenBlog
">15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b
</a
></b
>.
</p
>
95 <title>12 years of outages - summarised by Stuart Kendrick
</title>
96 <link>http://people.skolelinux.org/pere/blog/
12_years_of_outages___summarised_by_Stuart_Kendrick.html
</link>
97 <guid isPermaLink=
"true">http://people.skolelinux.org/pere/blog/
12_years_of_outages___summarised_by_Stuart_Kendrick.html
</guid>
98 <pubDate>Fri,
26 Oct
2012 14:
20:
00 +
0200</pubDate>
99 <description><p
>I work at the
<a href=
"http://www.uio.no/
">University of Oslo
</a
>
100 looking after the computers, mostly on the unix side, but in general
101 all over the place. I am also a member (and currently leader) of
102 <a href=
"http://www.nuug.no/
">the NUUG association
</a
>, which in turn
103 make me a member of
<a href=
"http://www.usenix.org/
">USENIX
</a
>. NUUG
104 is an member organisation for us in Norway interested in free
105 software, open standards and unix like operating systems, and USENIX
106 is a US based member organisation with similar targets. And thanks to
107 these memberships, I get all issues of the great USENIX magazine
108 <a href=
"https://www.usenix.org/publications/login
">;login:
</a
> in the
109 mail several times a year. The magazine is great, and I read most of
110 it every time.
</p
>
112 <p
>In the last issue of the USENIX magazine ;login:, there is an
113 article by
<a href=
"http://www.skendric.com/
">Stuart Kendrick
</a
> from
114 Fred Hutchinson Cancer Research Center titled
115 "<a href=
"https://www.usenix.org/publications/login/october-
2012-volume-
37-number-
5/what-takes-us-down
">What
116 Takes Us Down
</a
>" (longer version also
117 <a href=
"http://www.skendric.com/problem/incident-analysis/
2012-
06-
30/What-Takes-Us-Down.pdf
">available
118 from his own site
</a
>), where he report what he found when he
119 processed the outage reports (both planned and unplanned) from the
120 last twelve years and classified them according to cause, time of day,
121 etc etc. The article is a good read to get some empirical data on
122 what kind of problems affect a data centre, but what really inspired
123 me was the kind of reporting they had put in place since
2000.
<p
>
125 <p
>The centre set up a mailing list, and started to send fairly
126 standardised messages to this list when a outage was planned or when
127 it already occurred, to announce the plan and get feedback on the
128 assumtions on scope and user impact. Here is the two example from the
129 article: First the unplanned outage:
131 <blockquote
><pre
>
132 Subject: Exchange
2003 Cluster Issues
133 Severity: Critical (Unplanned)
134 Start: Monday, May
7,
2012,
11:
58
135 End: Monday, May
7,
2012,
12:
38
138 Description: The HTTPS service on the Exchange cluster crashed, triggering
141 User Impact: During this period, all Exchange users were unable to
142 access e-mail. Zimbra users were unaffected.
144 </pre
></blockquote
>
146 Next the planned outage:
148 <blockquote
><pre
>
149 Subject: H Building Switch Upgrades
150 Severity: Major (Planned)
151 Start: Saturday, June
16,
2012,
06:
00
152 End: Saturday, June
16,
2012,
16:
00
155 Description: Currently, Catalyst
4006s provide
10/
100 Ethernet to end-
156 stations. We will replace these with newer Catalyst
158 User Impact: All users on H2 will be isolated from the network during
159 this work. Afterward, they will have gigabit
162 </pre
></blockquote
>
164 <p
>He notes in his article that the date formats and other fields have
165 been a bit too free form to make it easy to automatically process them
166 into a database for further analysis, and I would have used ISO
8601
167 dates myself to make it easier to process (in other words I would ask
168 people to write
'2012-
06-
16 06:
00 +
0000' instead of the start time
169 format listed above). There are also other issues with the format
170 that could be improved, read the article for the details.
</p
>
172 <p
>I find the idea of standardising outage messages seem to be such a
173 good idea that I would like to get it implemented here at the
174 university too. We do register
175 <a href=
"http://www.uio.no/tjenester/it/aktuelt/planlagte-tjenesteavbrudd/
">planned
176 changes and outages in a calendar
</a
>, and report the to a mailing
177 list, but we do not do so in a structured format and there is not a
178 report to the same location for unplanned outages. Perhaps something
179 for other sites to consider too?
</p
>
projects / homepage.git / blob