LETS TALK BITCOIN

Episode 77 The Adam Back Interview

Participants:

Adam B. Levine (AL) Host
Andreas M. Antonopoulos (AA) Co-host
Adam Back (AB) Cryptographer and inventor of HashCash, Bitcoins proof of work system



Today is January 21
st
2014 and welcome to Episode 77 of Lets Talk Bitcoin, a twice weekly
show about the ideas, people and projects building the digital economy and the future of
money. Visit us at LetsTalkBitcoin.com for our daily guest blog, all our past episodes and, of
course, tipping addresses. [0:27]

My name is Adam B. Levine and today is special. Adam Back is a British cryptographer and
crypto-hacker. He is the inventor of HashCash, the proof of work system used by Bitcoin
and after we were initially introduced by mutual acquaintance Charles Hoskinson, I met
Adam, at the Vegas conference surrounded by a large huddle of attendees listening to him
speak in the hall. Adam very rarely does interviews and so when he agreed, without too
much reticence, I was pretty thrilled. Im a pretty sharp guy but I know my strengths and
organized what I hoped would be a half hour interview between he and Andreas M.
Antonopoulos the next morning, before our brunch meet-up. [1:06]

That day, we finished brunch and Andreas never showed up. Today, Im pleased to share
with you the reasons why. What follows is a very deep, lengthy and, many times, highly
technical conversation about Bitcoin. It will not be for everybody but I encourage you to
listen to it anyhow because its an important conversation and osmosis is sometimes just as
good as understanding. Enjoy the show! [1:33]


__________________________________________


Andreas M. Antonopoulos interview with Adam Back

AA: Hello and welcome. This is Andreas Antonopoulos from Lets Talk Bitcoin here in Las
Vegas for the Inside Bitcoins conference. Its a great pleasure today to have Adam Back,
applied cryptographer and somewhat of a celebrity in the Bitcoin space because of his long
history of contribution to cryptography in general but, essentially, some of the building
blocks of Bitcoin. Adam, welcome to the show. [1:59]

AB: Hi, good to be with you. [2:00]

AA: Adam, can you tell us a bit about your history in the space of applied cryptography?
[2:05]

AB: I was interested initially in PGP. When that first came out, I found it very interesting
that there were political and balance of power implications between individuals and the
state so that people could change... I mean, they could communicate with other people
without any possibility for interception and the ability to communicate privately is,
essentially, a right in many countries. You can think of it from the point of view that you
have some legal rights, you have a right to freedom of association, freedom of speech but to
strongly exercise them, you need to cryptographically enforce them. Privacy technology,
end to end encryption and things like PGP enable that, enable people to exercise their rights
and the ability to strongly exercise their rights enables people to build a democratic society
and I think its necessary for that. *2:55+

AA: Tools like encryption also opened the possibility for much more creative expression
which, nowadays, is becoming very difficult. This constant feeling of being surveilled...
ubiquitous surveillance is antithetical to democracy, its antithetical to free expression.
[3:13]

AB: Right. Thats very much true. I mentioned freedom of expression but, I mean, freedom
of association... so to get freedom of expression, you maybe need encryption so that you
can communicate privately between yourself and your colleagues or friends but freedom of
association actually requires another cryptographic property which would be anonymous
communication. If you have a legal right to have freedom of association, and society
recognizes this in law, in fact in most western countries, then you need anonymity
technology. You need to be able to send emails anonymously. [3:43]

AA: You were involved in many of the early developments in applied cryptography and you
dont just talk about the theory and philosophy of cryptography but you are involved in
innovating in both cryptographic applications but also cryptographic algorithms. In fact,
youre one of the six or seven people cited in the Satoshi Nakamoto paper on Bitcoin as one
of the contributors to the state of the art that came before, specifically with HashCash.
[4:14]

AB: As I mentioned, I became interested in PGP and then I subscribed to the Cypherpunks
list and bought a number of books on applied cryptography. I was actually doing a PhD in
distributed systems at the time but I kind of didnt make much progress on distributed
systems for a couple of years. Its a four year course so I took a big detour into applied
cryptography and basically spent all my time learning everything I could about that. I mean,
Im obviously interested in the technical aspect so that if you know the features available,
you can use them as building blocks to achieve new interesting properties for privacy
enhancing technology systems. You can look at it from the point of view of requirements.
Youd want certain requirements from the system so youd want to have freedom of
association and youd want anonymity. Many deployed systems have some non-ideal
properties because its quite technically challenging to achieve some of these properties. In
that context, I also became interested in privacy technology so, for example, anonymous
remailers. For a while, I ran an anonymous remailer and a problem I observed there, first
hand and obviously other people were experiencing this and concerned about it was that
because its anonymous, please can create mischief. I think people are generally happy with
the fact that anonymous speech could be unpopular speech. The right to freedom of
speech includes speech that you personally find unpleasant or derogatory or what have you.
People are generally willing to delete or ignore things; theyre not interested in if they see
an anonymous discussion; discussion on topics on like a public discussion forum with some
anonymous contributors. If the anonymous contributors are being disruptive, theyll
generally be ignored and people will be happy with that. There is also the consideration of
denial of service amplification so, for example, Usenet, which is a broadcast mechanism, the
anonymous remailer operators wanted to allow people to participate in public discussions
anonymously so there were mail to news gateways and direct news posting facilities within
the anonymous remailers. Some people, for whatever reason I mean, its not clear
obviously because they were anonymous and they werent explaining their motivations
would post large amounts of spam, essentially, to Usenet with no particular meaning, just
large volumes of ram and text and what have you. Basically, you could imagine to perhaps
discredit remailers; that remailers were a source of large volumes of useless junk that was
clogging up Usenet and every message that goes onto Usenet would basically be brought
through broadcast re-mechanism and arrive at millions of computers on the internet so the
overall volume of network resources used was quite large. [6:40]

I was kind of thinking about that problem and I happened to be reading about birthday
collisions in hashes, just on a technical basis and it occurred to me that a full birthday
collision, say on SHA1 at the time, it takes approximately 2
80
operations to create. Its an
immense workload to create that collision but once you have that collision, youd be able to
demonstrate it to somebody and they would be able to verify it in almost zero time. I mean,
in about the same amount of time it would take you to process a TCP packet, I mean, a few
thousand cycles on a CPU. I thought Well, thats interesting. Theres an ability to proof
work there. Maybe I can modify that algorithm so that I can have a scalable proof of work
a proof of work that I can, say, force it to take one minute or ten minutes, instead of a
billion years. I set about changing that algorithm. Now, one aspect of birthday collisions is
to compute them requires large amounts of memory and there is a time memory trade-off,
in fact. I viewed this as a somewhat unattractive property so I tried to avoid that and
switched to exploring partial preimages. [7:46]

AA: Can you explain that a tiny bit, what birthday collision is and what partial preimage is?
[7:51]

AB: Birthday collision it refers to the surprising statistical phenomena that if you go to a
party and you wonder what is the probability that there will be two people in the room with
the same birth date? Assuming birth dates are evenly distributed throughout the year,
surprisingly... and there are 365 days in the year, surprisingly you only need 23 people in the
room have the same birthday. For large numbers, you can approximately estimate that if
there are 1 million days in the year, you need about 1,000 people in the room, so its
approximately the square root. [8:20]

AA: Right. [8:21]

AB: When youre talking about cryptographic hardness, then youre saying SHA1 has an
output of 160 so thats 2
160
work operations to do a full exploration of its key space. [8:31]

AA: Thats like a brute force trying every possible output of SHA1 to produce it. *8:36+

AB: Right. If youre looking for a birthday collision the way you do that is you compute
lots of candidate inputs to SHA1 and get the outputs which are essentially random, store
them in a big table and you keep doing that until you find an output thats the same.
Because of the birthday principle that we just described, you would expect to do that in 2
80

operations and not 2
160
. Of course, that implies 2
80
memory or storage which is a vast
amount of storage. There are trade-offs where you can do more work and store less and
there are also cycle algorithms. [9:08]

AA: One example of that is in the coin business we have two coins that have drastically
different proof of work function and SHA256 and Bitcoin and then Scrypt in Litecoin. Scrypt
is much more memory intensive, less CPU intensive and SHA256 is all CPU. [9:25]

AB: Lets back up a bit to HashCash. Originally, I just modified the algorithm so to connect it
to a service... so youre trying to obtain service so you want to create a proof of work,
essentially, from this but that is bound to a service. You have a service string, lets say an
email address, a remailer address, a Usenet newsgroup and in Bitcoins case, the coinbase
you vary something inside that so a counter or something and then you repeatedly hash it
until you get a given output. The original proposal was to hash the service descriptor alone
to produce one random output and use the leading bits of that as a fair challenge and then
youd use a counter in the second one. You would change the counter until you find an
output that matched the first one. Thats a kind of fair challenge concept and, at some
point, two people Hal Finney and a guy called Thomas Boschloo independently suggested
that you dont need to choose a fair challenge because any arbitrary string, like the digits of
or the (??) string is also a fair challenge and slightly simpler. To verify the proof of work,
you only need to invoke one hash rather than two hashes to be able to compare the strings.
[10:36]

AA: Out of this, HashCash was born and the concept, as I understand and please explain it
to us if Ive got it wrong, is that by forcing people to do a bit of work and then proving that
they did a bit of work before sending mail through the remailer, that puts minimal burden
on someone whos sending a message with content because they have the commitment and
incentive to do it but for someone whos just spamming, it would put an unreasonable
burden and that doesnt scale. *11:07+

AB: We talked about the context of remailers and it was used for that for some period of
time and also as a anti-spam mechanism for email. People who are spamming are often
trying to... they have a profit motive and so it matters to them how many mails they can
send per second with their given resources. Theyll use thousands of bccs in the headers to
amplify the amount of mail they can send by having the mail server do some work for them
and they will max out their network resources and so on. What you can do with HashCash is
if each recipient of a mail requires a stamp that is bound to their email address, that means
that somebody whos sending an email cant reuse a HashCash stamp to send the same mail
to two different people so theyre using a unique stamp for each recipient. A number of
these tricks like using bcc to have a mail server send to lots of people at the cost of the
traffic between the spammer and the mail server and it going over the network once and
sending to a thousand users thats avoided because 999 of them would reject the message
if there was one stamp on it. Basically, its an economic argument that whatever their profit
margin is, which is obviously very slim because very few people would actually act on these
spams but they can operate with 1 in a million clicking through and getting $5 from that
because their cost is some tiny fraction of a cent. By requiring a proof of work, there are
only so many proofs of work they can do in an hour and so the number of mails they can
send per hour maybe drops by 1,000 or 10,000 or 100,000. You can vary the proof of work
to tune this effect so basically, you want to have as high a proof of work as is not
inconvenient to a regular user who is not engaged in spamming. If youre sending an email
to a friend or colleague or family member and you click send, it takes 30 seconds or a
minute. If its computing the stamp while youre composing the email, youre essentially,
not really going to notice and its not going to get in the way. Another thing to consider
about the HashCash proof of work is that its non-interactive. The challenge that you use to
compute the proof of work is done on your own computer. You dont need to talk to
anybody first so you dont need to contact your recipient or the web server that youre
going to provide the proof of work to, to ask it for some challenge or something to work on.
You choose, randomly, a fair challenge. You provide a proof of work that you did work on
that challenge and that challenge also involves the recipients resource name and then you
send it to them. That makes it, basically, in distributed systems terms, 100% scalable. There
is no new communication overhead so it can be used in essentially any protocol and scaled
to internet scale. It could be used in email without having any communication effect.
[13:44]

People used it... (I mean, apart from remailers and mail) it was also used in larger quantities
for name squatting. The I2P anonymous networking protocol, which is a kind of Tor
competitor, has a pseudonym concept and to obtain a pseudonym, produce a much larger
proof of work so thats basically to discourage name squatting because people come along,
they can ask for names cheaply, at low cost, and so they would try to take all English word
dictionaries or all common names and there would be no interesting names left. You can
see an aspect of that within Bitcoin. Bitcoin has to contend with the Sybil attack which is
that when its voting, which transaction is correct. Youve got many people in the network
and you somehow have to agree amongst this distributed system which payment is correct,
which payment came first and that the payment is valid with respect to its preceding
transaction input. The same situation is name squatting and an analogous situation exists
for Bitcoin which is that if somebody has an interest to influence the vote, so the vote is just
one person, one vote or one computer, one vote, they can do a Sybil attack. If the system is
looking at IP addresses to try to enforce one person, one vote, its very easy for people with
a botnet or cycling IP addresses to perform, whats known as, a Sybil attack which is that
one person can pretend to be a million people (??) voting. Bitcoin uses the proof of work to
say you get one vote per CPU cycle, essentially. Its not fair in the sense of one vote per
person but its less abusable than a situation of one vote per IP address or something
unenforceable. At least its strongly enforceable, shall we say. *15:31+

AA: HashCash - you first published the paper in 2002 and then in 2008 it was cited in the
Satoshi Nakamoto paper and Satoshi suggested using it in order to do proof of work on a
coin, a digital cash system which is probably now the most widespread application of the
concept of proof of work and certainly one of the more successful weve seen. The original
concept of one CPU, one vote now weve seen this enormous explosion in hashing powers,
because of the economic incentives existed and they were very good economic incentives,
weve moved very rapidly from CPUs to GPUs to FPGAs and now to ASICs and there is some
concern in the community at large and some discussion, a recurring discussion (probably a
very good discussion to have) about the risk of centralization, about the possibility of
organizations with economic resources to acquire silicon from fabs to be able to create
massive proof of work farms, essentially and either dominate Bitcoin with a nefarious
purpose or simply dominate mining in order to funnel a lot of the rewards in their direction.
Do you share that concern? Do you see the argument and whats the risk of centralization?
[17:14]

AB: Yeah. I do share that concern and actually when I first joined the Bitcoin dev forum
earlier this year, my reason for joining was to articulate this exact concern. My concern was
that (and I guess many people arrive at this concern) is that because using SHA1 as the hash
function in HashCash, the proof of work used in Bitcoin because its so simple, its easy to
run on FPGAs, GPUs, ASICs to a significant and dominating advantage compared to less
specialized hardware. [17:46]

AA: Like a general purpose CPU. [17:47]

AB: Right. I mean, we saw initially, the initial version of Bitcoin, people were mining it on a
CPU. Quickly, people moved to GPUs and after that to FPGAs and then ASICs and each
move typically will render the previous generation of approach of mining type of hardware
used, completely unprofitable. It means that, over time, basically you cant mine unless you
have an ASIC and so CPUs, everybody has CPUs and they have multiple uses. GPUs, you can
generally get GPUs because people want to play games with them, video games and what
have you. As I understand it, they will also supply problems with GPUs because Bitcoins
were buying up the entire stock of GPUs but at least thats something that consumers, the
man in the street, can have a fair chance of buying as opposed to, lets say, a large company
monopolizing supply or something like that. Thats potentially an argument for Scrypt so to
replace SHA256 in HashCash. Just to back up a second, many cryptographic algorithms are
based on building blocks so we have building blocks such as SHA1, SHA256, AES and so on.
For example, with HMAC you have HMAC-SHA1, HMAC-SHA256, HMAC-MD5 and so on, so
with HashCash, its very similar to HMAC. There is HashCash and the original HashCash was
using SHA1, Bitcoin uses HashCash with SHA256 iterated twice and Scrypt uses HashCash
with the Scrypt internal hash function. I think theres a slight confusion about Scrypt
because Scrypt used for its original purpose is to stretch passwords, to make passwords
harder to grind. In that context, the Scrypt has an iterate at typically 10,000 or 100,000 x
iterations. It has its own hardness but that hardness is not being used within Litecoin and
other Scrypt users. HashCash Scrypt is really HashCash and the internal Scrypt function or
Scrypt iterated once, essentially. It makes use of the memory hardness but it doesnt make
use of the Scrypt iteration and the reason that you cant do that is if you used Scrypts
hardness, by using Scrypts iterations, then when you came to verify the proof of work,
youd have to repeat the work so it would have an extremely expensive verification time.
Theres a HashCash using SHA256 versus HashCash using Scrypt internal hash function
debate. The argument is that because the Scrypt hash function artificially consumes
memory, it does actually have a time memory trade-off but its still more expensive in terms
of memory that it should be more resistant to implementation in ASICs. People use that as
an argument to say that Scrypt using Bitcoin clones may be more interesting or maybe more
resistant to centralization risks. There is an interesting counter argument which is that
SHA256 is a very simple algorithm that was originally designed to be simple to implement;
simple and efficient to implement in hardware. There are circuit layouts for SHA256
available for free download on the internet so potentially, even somebody with, rather than
industry experience or academic experience, in circuit hardware could make a small (??) of
mining hardware themselves with their own savings. Conversely with Scrypt, because there
is a barrier to entry, it turns out its not impossible to make an ASIC implementation and, in
fact, there are rumors that, and even announcements that two companies are doing just
that right now. As that succeeds, there is actually a much larger technical barrier to entry to
create Scrypt ASICs, so it actually turns out that the centralization risks are actually worse
with Scrypt. [21:19]

AA: Only the specialists will be able to design those circuits. There will be more limited
supply. [21:23]

AB: I mean for example, it needs low latency memory and as a circuit design, its much
more complicated. Another aspect of this argument is that in an ideal world, you want tens
of thousands of people to be mining, power users in their garage, people mining just for
curiosity on a GPU or on a small ASIC, a USB ASIC and we see some of those, just so that the
mining power is distributed because there are specific risks that arise when policy risks
and... Im possibly less concerned about the profit risks because, basically, anything anybody
does to mine more efficiently means that the overall resources consumed to complete the
Bitcoin distribution, until we get to 21 million, will consume less electricity and result in
somebody getting some profit, which hopefully they will reinvest in a Bitcoin industry or in
general, whereas if everybodys mining less efficiently, more resources get consumed and so
there is less money released to Bitcoin related industries. The argument for ASICs is will we
get decentralization with ASICs? The question is about supply and there are some
interesting economic dynamics in there. If somebody has put the minimum investment in to
make some ASICs, they have some incentives to consider. Will they mine them themselves?
Peoples first reaction is typically that well, this is a machine that lets you print virtual
hundred dollar bills. Why would you sell it? Surely youd use it to mine as fast as you can
and keep the proceeds? One counter argument to that is the mining profitability once the
system bootstrapped, perhaps after the first 3 or 4 years or so, the mining profitability
margin dropped considerably so there were actually risks to mining. For example, many
people ordered ASICs from companies on pre-order. By the time the ASICs arrived, it was
kind of debatable whether it was even break even that they would be able to, for the
electricity cost, recoup their hardware investment. [23:18]

The other dynamic is that people who are selling ASICs, there is a question of the hardware
manufacturers that are making ASICs. I initially thought what we need is a KickStarter so
that there is free ready availability of ASICs, if you subscribe to the supposition that people
who manufacture ASICs are hoarding them for internal use, so we need maybe a KickStarter
with at cost or non-profit availability of these things to ensure decentralization. Actually,
the economic argument that the ASIC manufacturers are operating under are interesting
and their argument is that there is a natural incentive for them to not over produce and
over supply because if they do that, because the difficulty will ramp up, the profitability
margin at a given Bitcoin price will drop to close to zero. [24:02]

AA: For everyone, including their most recently shipped customers who will be annoyed.
[24:06]

AB: Right. That will mean that they wont have follow on customers, people wont buy any
more or theyll have to sell them at a slimmer margin, so theyll destroy their own business
and they would remove profitability. There is a natural shelling point for them to sell at a
margin so they make a profit, their customers make a profit but they dont make too much
of a margin so that somebody else has an incentive to step into the market or optimize their
own ASIC, their computing ASICs to match the efficiency. It basically becomes an
economically balanced supply function. [24:39]


____________________________________________


ADVERT:

Shop smart with your Bitcoin and get 3% back with Gyft. On Gyft, you can get giftcards with
Bitcoin. Choose from over 200 retailers including Target, GameStop, GAP and more. Gyft
makes it easy to shop on Android or on the web. There are no additional fees and when you
shop with Bitcoin, you get 3% back. Go ahead! Try Gyft. Thats Gyft.com. *25:16+


ADVERT:

Hi listener. Here at Lets Talk Bitcoin, were building a global network of correspondents
able to contribute on the ground perspective when cryptocurrency related information
comes across their filters. If youd like to join our global conversation, send an email with
your name and geographic or cultural niche to apply@letstalkbitcoin.com. Just like Bitcoin,
the only barrier to entry is your time and good work. Thanks for listening. [25:45]


__________________________________________



AA: Taking this a step further, weve really squeezed out all of the optimization that we can
get down to 28 nanometers and, at this point, the actual algorithm SHA256 cant be
optimized really not much more and certainly not orders of magnitude more and so were
locked into Moores Law. From this point on, its really about chip density and access to
fabs but the other interesting effect thats happening is that now the density of the chip
cant change but the number of chips you can put within an enclosure, your ability to
dissipate heat and feed power to it has pushed this game into the realm of high density data
centers. Things like liquid cooling are coming back, were seeing these 19 4 unit rack
mountable hashing rigs that are even going to push the limits of data centric capacity with
25kW racks and high density, high thermal output situations which again, makes it a much,
much more specialized function, a much more specialized industry which requires large
capital investments as well as skills and personnel to manage. Essentially, now there is a
building that comes with it; thats wrapped around this hashing infrastructure which is the
data center and its cooling and power facilities. Do you see that as an additional danger for
centralization? [27:06]

AB: Yes, that clearly is a danger for centralization. At the beginning of your comment there,
you mentioned as the ASICs were introduced, they were in a process of catching up with
Moores Law so weve got a kind of S curve thats terminating in Moores Law and then
following CPU technologies. Actually, talking with some ASIC mining vendors yesterday, Im
surprised to hear that theyre shipping 20 nanometers in the first quarter next year which
may mean that theyre surpassing CPU vendors in being the first to produce the next
generation from 28 nanometers on the TSMC line. It may be, which is kind of them using a
situation that there is actually more economic incentive to push harder and faster to get to
20 nanometer and 14 nanometers for ASIC miners than there is for CPUs. Actually, there
are some advantages that ASIC hashing has over CPUs, in terms of simplicity because they
dont really care so much about error rates because you have many, many hashing units and
if some of them fail, you just disable them. They can probably tolerate higher error rates,
they can adopt earlier technologies when the error rates are higher, they can push the limits
harder and still get very useful function from ASIC hardware. [28:18]

AA: We should be paying attention to the ASIC market as the new front runners of Moores
Law and all of the economic incentives that push us there. [28:26]

AB: Yeah. I mean, its kind of a curious situation but it seems to be whats happening if the
ASIC mining companies are able to deliver on their projections. [28:34]

AA: Just a quick clarification here. Were talking about centralization and some people
confuse this as a concern about someone being able to mount a 51% attack. For me, this is
a much simpler problem which is that every single feature development or change in the
code or other modifications of the core Bitcoin protocol has to go through a process of
consensus and adoption by the miners and by having a very broad population of miners, you
expose that decision to the broadest consensus mechanism of voting possible. I see that as
a bigger concern than the 51% type of attack. Am I down the right path or am I missing
something? [29:13]

AB: One of the concerns of centralization is that you might see policy enforced at the
miners and if the miners are extremely powerful and you get the same situation with pools,
in fact, even though the pools mostly dont own their own mining resources, just because
most people are not using getblocktemplate. The situation you have is that the mining pool
or the centralized miner is a full node in the network, is looking at all the transactions,
constructing a candidate block and performing proof of work on it and with the pools,
theyre doing the same thing but theyre providing the block (or the hash of the block, the
coinbase) for the individual end users doing mining under that pool to work on. Thats
actually a bad situation because it means that centralization is, in the case of pools,
artificially centralized in the pool operator where there is no particular reason that the pool
users couldnt be full nodes and thats what getblocktemplate provides. [30:07]

AA: Essentially, the pool operator doesnt even need to mine at all. They just need to be
running a pool and they get the vote of every participant in the pool, as long as theyre not
obnoxious about it and cause everyone to leave the pool. It puts a lot of power in their
hands without any hashing. [30:23]

AB: Right. I think the risk that is created for centralization is kind of policy risk so you could
imagine that as mining pools, which own their own hardware or which have hardware that
is leased by users on a mining contract, as they become bigger enterprises, they may be
stock market listed companies or limited companies so theyre vulnerable to court orders
within their jurisdiction and the interest to serve them a court order is relational to their
proportion of power in the network. If somebody wanted to block a given set of
transactions or a given receiving address or a given sending address or a selection of sending
addresses, they could issue a court order, maybe even with a gag order so that its not clear
to anybody else, so theyre not allowed to talk about the fact that theyre blocking these
transactions. If, in a few years, 90% of the mining power is in the hands of a few dozen
stock market listed companies across a few countries in the world, if somebody can issue
court orders on significantly more than 50% of them, they can disrupt payments. Bitcoin
provides a number of interesting new features relative to the banking network so the fact
that you cant seize client assets, that you cant block individuals from receiving payments
and we saw this with Wikileaks. As I understand it, the US government applied to the
relevant department to ask for Wikileaks to be put on an embargoed recipient list and that
was rejected. Outside of the established legal process, nevertheless, senior politicians
contacted payment vendors and persuaded them, outside of the law, to block those
transactions. Thats another example of the risk of centralization. The credit card vendors
and PayPal are in a very centralized position so we have to avoid this kind of situation
occurring in Bitcoin. [32:01]

Actually, I made a technical proposal to combat this situation. There are number of things
you can do about centralization. Obviously, one of them is to try and combat centralization
technically to introduce diseconomies of scale or encourage users to choose their blocks
when theyre mining with a pool. There is no reason for the user not to be a full node,
choose their own blocks and that obviates the artificial possibility for the pool to exercise
their voting power. They can exercise their voting power directly while still benefiting from
the reduced variance that comes from operating through a pool. Im going back to this
proposal I made, to do with avoiding policy attacks from large miners. If we imagine a
situation where there are 10 mining pools in the world. They have approximately 10% each
but theyre stock market listed companies and its very easy for them to be served with gag
orders and court orders and so on and there is a significant policy attack going on. They are
blocking transactions and so on. In this situation, what you want to do is to be able to
transact where they cant block transactions on the sending side, they cant block senders
and they cant block recipients. It turns out that you can do that, surprisingly. The way that
you do it is you, essentially, to simplify slightly, encrypt the transaction that you would have
sent onto the Bitcoin blockchain with symmetric key encryption, in such a way that if its
double-spent that can still be detected. The miners validate that the encrypted transaction
hasnt been double-spent in the normal way and obviously, they cant... because its
encrypted, they cant tell who the sender is, who the recipient is, what the inputs are, how
much moneys involved at that point and yet theyre still doing a partial, simplified
validation - the expensive part of the validation, the hashing. After, say, six blocks or when
the recipient needs to respend the money theyve received and the users can privately send
the encryption key between them. If Im sending you one of these encrypted transactions, I
can send the encrypted transaction on the blockchain and I can privately send you the key
or I can encrypt the key to your public key and attach it to the encrypted message or we can
just simply wait six blocks. Once we broadcast it, we wait six blocks or so... sorry, six
confirmations or so until its been confirmed by the miners and then we release the key to
the network. When we release the key to the network, we dont need any validation of that
key because its self-verifiable against the encrypted message. If the keys wrong, the result
is garbage and the check sums fail. In this way, you can extract policy immunity even in a
situation of centralized control and this has been discussed under the heading of
Committed transactions Hidden transactions. If, in this situation, the miners had a very
strong incentive, for some reason, to undo a transaction so they learn, after the fact, that
the transaction that they would have liked to block has gone through. In this situation,
maybe they expend some enormous resources or hire some rented equipment to undo the
transaction. In order to do that, they have to fight against their previous work. [34:50]

AA: Recalculating the six blocks minimum that have elapsed? [34:53]

AB: Right. Theyd have to orphan their own previous work. Maybe, if there are enough
court orders, enough of these centralized miners, they can do... its unprofitable but maybe
a court can order them to do that or maybe a court can pay them to do that, if they care to.
That, kind of, partly undoes the benefit of what were talking about. It is some cost but they
can still do it. There are two things you can say about that. One thing is that you can very
trivially frustrate that and make that approach completely impractical, which is that you can
do it again. You can publish another small transaction every block. You can publish
hundreds of small transactions every block and not reveal the keys. Every time they redo
the work, you reveal another key. Basically, you could stall their mining contributions and
while theyre doing this, people are not engaging (??) resistance are moving forward on
alternative chain. I think basically, what it comes down to is that the next stage from this is
that people say Well, maybe the miners will demand that encrypted transactions not be
allowed, that they not be used, they simply reject encrypted transactions but I think thats
actually a technical misunderstanding and that essentially, the end users with the wallets
that decide on the protocol. The miners cant change the protocol, even though they have
all the hashing power or say, a large proportion of the hashing power. All of the hashing
power is slightly more complicated. Say that something like 50-60% of the hashing power is
still in private hands, essentially, the end users with their wallets and not the miners
private or public, privately owned as in power users or publically listed companies. Neither,
or the combination, of those actually has voting control over the protocol and the reason I
say that is, say that we implement encrypted transactions into the Bitcoin protocol and the
miners try to vote against this, at some point, now if they vote against it, it means they drop
the transactions. At that point, theyve basically created an altcoin with no users. The users
continue with the miners that dont implement this policy. *36:48+

AA: It resets the difficulty somewhat. [36:50]

AB: It does and thats why I mentioned that its difficult to do that if 90% of the hashing
power is in the hands of your enemy, shall we say, in security terms you talk about the
adversary or enemy. In the case that hashing power is somewhat distributed but
geographically distributed in different countries and some non-trivial proportion in power
user rules a small company has and the jurisdictional arguments are non-trivial as well, in
the sense that it can be more difficult to obtain synchronized court orders across many
jurisdictions. The mining hardware people I talked to yesterday, and discussed these kind of
risks with, said they have shipped hardware to hundreds of countries and theyre not all sold
in large batches, theyre going to smaller orders as well. It is actually, relatively distributed
and so in that kind of picture, if we can maintain that picture and use encrypted
transactions, it turns out that even though the users dont have the hashing power, they can
still have the protocol control and I think thats interesting. Its an alternative form of
defence. If, technically, it turns out that were unable to provide the economies of scale or,
for whatever reason, discourage users from using pools in a manner, like using the wrong
interface, using it where they let the pool do the voting, they should do it where they do the
voting themselves. There is a mechanism to do this called getblocktemplate which is
offered by the Eligius pool which has about 10% of hashing power and actually much lower
fees than the other networks. I always wonder why Eligius doesnt have a much higher
portion of the network. [38:19]

Going back to the encrypted transactions, another interesting observation is that it turns
out that you can respend an encrypted transaction in encrypted form, which is kind of
interesting. If I give you an encrypted transaction, you have the key to verify the value
because you can decrypt it and so you can go back and see where it came from a mining
event or a previous unencrypted transaction where the values are exposed and the chain of
custody of ownership is exposed. You can follow that trail but you can turn around and
make a new encrypted transaction referencing your encrypted transaction as the input and
get that validated and so spending it to somebody else and then you provide them,
privately, the key. You dont broadcast the key, in this case, but you provide privately the
key to my input transaction and to your new transaction and the recipient can verify the
chain so they can see that your transaction appears to be valid and it has the required value.
The inputs from your transaction, they have the key to go back and fetch the encrypted
transaction that is the input, decrypt that and then validate it. In that way, you can have a
new, kind of transaction privacy model which is that only the parties to the transaction can
see who sent the transaction, who received the transaction and the amounts involved in the
transaction. You can, essentially, keep this up indefinitely. The only limitation which Ive
not found a nice way to address so far is that the privacy gets eroded over time, so if you
imagine 10 people are involved in this transaction chain. The most recent transaction
recipient can see the entire history of transaction payments. [39:49]

AA: Right. You can look backwards but not forwards. [39:50]

AB: Exactly. Somebody in the middle can look backwards but they cant look forwards.
There is some kind of privacy in that not everybody sees everything but the latest person
sees everything. If everybody was using encrypted transactions, payments get mixed
together and eventually, everybody would be able to see everything. Still for perhaps a
private group of people, who are relatively close knit, they could retain some privacy or
retain a wallet that segregated addresses that were used for encrypted transactions. I think
this is an interesting and desirable potentially security model if we can find a way to make
this work in a general sense. It retains a possibility for the conventional investigative
procedures that law enforcement use which is they follow a particular crime that theyre
trying to investigate and they look at external parties that interacted with the person who
committed the crime. The car rental company, the hotel and they will go to those entities
and issue them with a subpoena for their business records. You could see that, working in
this context, that we have encrypted private transactions that flow between a group of
people. Some of them will be businesses that are completely innocent and are uninvolved
in this hypothetical crime. They can be supplied with a subpoena and reveal the
information they have and provide visibility inside this but, at the same time, phishing
expeditions and the kind of mass scale, a priori network analysis or funds flows, private
communications and these kinds of things, is prevented. I think most people in society
viewed that and actually, the law views that as the correct balance for society so for
example, many of the things the NSA has been doing with harvesting information, it seems
is illegal and even the author of the relevant law in the US has come out... [41:26]

AA: Hes called Sensenbrenner who said this is not what we intended with the Patriot Act.
[41:30]

AB: Even the author of the Patriot Act says that the way theyve been interpreting or
abusing this Act is not legal from his perspective and theres a whole side story to that.
[41:39]

AA: Youre providing a neat solution where the type of targeted investigative analysis of
transactions is possible by finding the legal entry into the chain of transactions and
compelling disclosure backwards but only on a selective basis but you cant scale that up to
ubiquitous surveillance, thereby forcing them to revert to the original mission which is
investigating specific targets rather than all of us, a priori. [42:06]

AB: Right. Thats what society authorized. All the things we see above that are
unauthorized and essentially, illegal actions. [42:11]

AA: Lets talk a bit about the future of Bitcoin. One of the, I think, key understandings is
that Bitcoin as an invention, the combination of a distributed asset ledger, with proof of
work, that enables both currency and many other potential applications in the future
Bitcoin as a protocol, Bitcoin as a network can survive Bitcoin, the currency in that Bitcoin
the currency could fail and we could start a different version or new version or implement
an altcoin that provides better solution to our problems. Obviously, none of us want that to
happen but one of the arguments is that all of the cryptographic algorithms and the core
mechanisms can be tweaked to generate other outcomes or to highlight different properties
of the system, if we find that some of the properties that were in the original
implementation are not suitable. [43:25]

AB: Right. You see that argument put forward for supporting altcoins and personally, Im
not really a fan of altcoins and I have a couple of reasons for this. Bitcoin was a kind of one
off event. The creation of a new concept of digital, virtual scarcity, so it really is a kind of
digital gold a scarce virtual commodity. I think that its not clear that its desirable or good
for even the confidence in the concept of digital virtual scarcity if there were to be another
event where an altcoin were to take over. I more push the view that we should add the new
features that we need to Bitcoin. It can be challenging for Bitcoin itself to accept too many
innovative changes too fast because they have an extremely high security bar to protect the
value which is in the $10bn plus range now of the system. They have the kind of quality
assurance requirements of a flight control system of an A380 Airbus super jumbo or what
have you. [44:23]

AA: Being patched while in flight. [44:25]

AB: Yes. You have to be really, really careful about doing that and so they are rightly
conservative with adding features. I try to work out... I think Ive found a plausible
approach. They have a testnet where they put bug fixes or small enhancements to have a
test environment to shake out things but I think thats not quite the same things as being
able to add new features. For example, you notice that many of the scripting languages
features are disabled so that some interesting smart contracts are not possible and that, it
turns out, the input values are not within the transactions, theyre not within the validated
part of the transaction so it creates problems for offline wallets. They cant easily verify the
values involved and so they have to import much more data than would be necessary so it
kind of makes that complicated. There are many interesting things that could be added and
you see that in terms of altcoins focusing on adding features, adding trading features or new
transaction features. For example, Mark Friedenbach proposed a very nice, clean set of
extensions to the scripting language to support more trading functions; very much the
cleanest set of extensions Ive seen posed for being able to issue an order and for anybody
to match that atomically, directly and other clear next step trading functions. [45:46]

AA: That would allow the kind of distributed exchange for Bitcoin or possibly Bitcoin into
other currencies or even other types of shares that solves the big single point of failure right
now of a concentrated on-ramps and off-ramps of the exchanges. [45:59]

AB: Right. You see with ColoredCoins an approach to add new concepts by watermarking
or tagging Bitcoin so you can take a nominal value Bitcoin and attach an external value, so
like a US Dollar value from an issuer or a gold value from a gold depository. You have an
issuer risk there but thats implied in any coin of non-digital virtual scarcity asset, essentially,
so thats unavoidable. Coming back to the way that we can move Bitcoin forward, so I think
its actually detrimental that people try to implement futures outside of Bitcoin. I mean, it
seems that there is a profit motive that they hope that by adding some nominal feature to
an altcoin, they can mine it early and they can become very rich. Most of the altcoins
actually have no transactional volume; literally, the blocks are empty. From a transactional
point of view, you can consider the value of a virtual currency or any currency as some kind
of metric involving the amount of money in circulation and the velocity of that money that
gives a kind of metric of the intrinsic value of the currency. We dont know exactly what
proportion of the Bitcoins market cap is intrinsic value or if its speculative value but clearly
it has a very high intrinsic value because it provides unique functions to users, it has
deployment, it has payment processors, integration, hardware and so forth and all of the
altcoins have none of this and no transactions. I view them as sort of interesting
experiments... [47:24]

AA: Laboratory... and in the future, when we look at Bitcoin, there is sort of this balance to
strike between modifying, if you like, the core protocol changing the transaction script or
changing core features around mining, proof of work etc versus leaving that mostly alone
and implementing some of these things in layers above by some of the techniques that have
been demonstrated to introduce other layers of protocols within the transactions. Some of
the core capabilities of the protocol, and weve been discussing anonymity and privacy in
transactions, these are things that need to be implemented at the lowest level layer
possible. Where do you see that balance? What do we really need to get into the core
protocol before we stop messing with it and then say from now on, really limit the amount
of development? As with TCP/IP, it reached the point where it was good enough and then
we could move most of the development to the layers above and just let it ride the network
effect and become more and more dominant simply through its broad utility and adoption.
[48:28]

AB: I think that should be the correct target that you want to arrive at eventually, core
properties and essentially never change the base level after that. Unfortunately, Bitcoin has
some non ideal properties so, for example, the fungibility layer is imperfect which is to say
the reason... and maybe people dont appreciate this that... people say that Bitcoins an
anonymous ecash system but actually its not that anonymous, if not used carefully and its
not that anonymous even if used carefully or it is very easy to make mistakes and all the
values and exchanges are public. The reason to have anonymity at the transaction layer is
to support fungibility which is the concept that $1 bill should be exchangeable for another
$1 bill and that if you received a $1 bill that was, in the distant past, involved in a crime and
presumably pretty much all $1 bills are, that as a result of criminal investigation, the $1 bill
in your pocket shouldnt be seized or evaporate. *49:22+

AA: Right, whereas something that was resolved in the 1700s in Scotland, through legal
proceedings and has become part of the common law of currencies for the last two
centuries and yet, in Bitcoin, were having this discussion at the moment of blacklisting and
whitelisting and redlisting and various types of filters, destroying the fungibility I see this
as an extreme threat that could effectively be an extinction level threat to Bitcoin if
implemented because it would shift the power from the two parties involved in the
transaction to a third counter party that controls the list. [49:53]

AB: It seems to stem from a misunderstanding about where Bitcoin gets one of its main
core advantages. One of Bitcoins main core advantages is that its immediately and
instantly settled as an irrevocable payment. That reduces the traditional costs of arbitration
and fraud management, so you see with credit cards due to arbitration and fraud
management, they have fees at sort of 3-5% plus 50 cent plus per transaction. PayPal has
perhaps some kind of similar cost direction because they also have to handle the same kinds
of issues. As I was saying, there is a very clean transaction layer which is kind of
mathematically perfect. If you introduce dispute arbitration into the transaction layer, you
introduce costs into it, the immediate final settlement goes away, now merchants have to
buy insurance or engage escrow parties to do arbitration and none of these things are free
so, at that point, Bitcoins transactional cost advantage will disappear. There will be no
transactional cost advantage versus credit cards. [50:46]


_________________________________________


ADVERT:

The BitGive Foundation is a non-profit charitable giving organization, leveraging the power
of the Bitcoin community to improve public health and the environment worldwide. Help us
demonstrate the significant impact of Bitcoin in addressing these critical issues on a global
scale. Support international giving in Bitcoin. Please visit our website at
www.BitGiveFoundation.org. Thats www.BitGiveFoundation.org. [51:22]


ADVERT:

Lets Talk Bitcoin is heard each week by thousands of people who are participating in the
new digital economy. Our listener base of Bitcoin owners, miners, investors, technologists
and merchants is growing fast. We offer a limited number of short advertising slots in each
show to keep our listeners engaged and to provide maximum impact for our sponsors. If
youd like to talk to us about Lets Talk Bitcoin, send us an email at
sponsors@letstalkbitcoin.com. [51:58]


_________________________________________



AA: Another way to look at it and something Ive been talking about a lot is the concept of
Bitcoin neutrality. The internet provides neutrality as to sender, recipient and content of
message. It provides routing of these messages and packets without considerations as to
sender and recipient and in Bitcoin we have the same thing the sender, recipient, value
and content of the transaction script do not determine whether your transaction will be
routed, simply whether it is a valid transaction and whether the output can be properly
verified and used as an input in the next transaction. These schemes break that neutrality
and would introduce a level of centralization that would not allow you to do innovation at
the edges any more. [52:44]

AB: Yeah, I guess thats true also. What I was thinking of in terms of the idealized features
for a distributed electronic cash system we were exploring this in 1998/9 timeframe with
Wei Dais b-money. Hal Finney was involved and some anonymous people, one of whom
may have been Satoshi, its not clear. Nick Szabo made a related proposal called bit-gold. It
involved broadcast to avoid the risk of centralization. Initially, it related to a specific
previous third experiment with a centralized solution. There was a company in the 1995 era
who had an electronic cash technology invented by David Chaum, whos really kind of the
progenitor of electronic cash because he invented blind signature with very interesting
applications for electronic cash and is a very clever cryptographer. He started this company
in the Netherlands called DigiCash and they put up a demonstration electronic cash server.
Their end game was to obtain banking licences or partner with banks and exchange
electronic cash tokens worth exactly $1 for $1 so there is no kind of virtual scarcity involved
but there is immediate and final settlement and also the concept of the user holding their
own token. Its kind of virtual, digital bearer of certificate an electronic version of a bearer
bond. [54:04]

AA: Yeah, full control in the hands of the person who has possession. [54:08]

AB: They put up this demo server with no banking connection a kind of Bitcoin faucet
equivalent thing which was you could just email them and they send you a few coins.
People on the cryptography lists were very interested in deploying electronic cash because
you can immediately see with any kind of encryption, or privacy related, or network privacy
related technologies, or internet services, that you can make things work more smoothly if
you can have money involved. Sometimes its difficult to have money involved where there
is no transactional privacy; if youre trying to have privacy related services. People pretty
much viewed electronic cash as the Holy Grail of the privacy technologies they were
exploring. This Beta Books server, people got interested and thought Well, why dont we
start buying and selling things and see if we can inflate the balloon. Theres scarcity.
DigiCash promised to only every issue one million of these and to leave it running, basically.
I sold some T-shirts relating to encryption policy at the time and other people sold other
things. If that had been able to run its course, perhaps within a year or two within a
community of a few thousand interested people, that might actually have floated and
achieved a value. Unfortunately, around that time, DigiCash went bankrupt and the server
got shut down and because of its architecture, the double-spend database which defines
the value basically, you end up holding a coin that you fully control but its defined with
respect to a double-spend database. If the double-spend database disappears, nobody
knows whether your coin was already spent or not and they have no proof of that so all the
coins became worthless overnight. It was within that context that Wei Dai proposed b-
money and I presume Nick Szabo proposed bit-gold also. Basically, trying to distribute that
double-spend database and also Wei Dai, particularly, had proposed to try to create a
distributed electronic currency without a banking interface by using HashCash as a kind of
virtual mining function. Some aspects of his proposal were kind of slightly vague or high
level broad brush strokes but I think, one of the things was you would send a HashCash
proof of work, which is non-transferable to a group of cloud servers and they would issue
with a blind token or would track ownership in some not fully defined way. In this
discussion, I proposed that if you mined a coin yourself, you dont need to exchange it with
a server. It is a virgin coin so thats kind of the Bitcoin virgin coin concept the virgin mined
coin that is valid in itself. Nick Szabo had a kind of related idea involving a collectable
market so you can see that when you mine these things, theres Moores Law going on and
people jumping in so that you get bigger and bigger HashCash stamps over time.
Apparently, there is a collectable market so, I guess, Nick Szabo has more experience in
markets and law and other aspects of the existing financial eco-system. He had picked out a
specialized kind of market, called a collectable market, where apparently people... specialist
traders will piece together collectable assets, like rare postage stamps and things like that
and put them together into a bundle with a fixed value, even though the components have
different ages and scarcities and values. He was proposing a collectables market to stabilize
the value of these changing, increasingly less scarce stamps. Unfortunately, neither of these
systems had any way to control inflation so we were thinking... I mean, actually my design
consideration going into it is I was aiming for inflation adjusted US dollar. Basically, what I
was trying to achieve was that if you wanted to get a US dollar in electronic cash, what you
would do is you would burn a US dollars worth of electricity. If you didnt have a time on
your computer today, you would go rent it from bit-compu farm and within a few seconds,
youd get your US dollar and youd pay your US dollar in fees. Thats an interesting and, in
fact, extremely fair distribution model because nobody gets rich and you can get it on
demand and there is no limitation and there is no supply curve. It fully meets demand and
once you have a dollar, you cant convert it back but you can use it within the system. Its
some kind of stabilization (??) [57:55]

AA: Its like virtualizing that dollar, essentially. *57:57+

AB: Right. Its kind of an attractive proposition but unfortunately, I kind of stalled on that
because you cant really do that... I mean, you can do it. Somebody can buy a computer
every month, the most efficient, cost effective computer and measure how big a stamp it
can produce for a dollars worth of electricity and set an exchange rate but unfortunately,
thats a centralized event. That rate setter becomes the Ben Bernanke or the monetary
policy unit of the virtual currency and thats undesirable. You want a distributed situation
so you could have multiple people doing that but its still undesirable and it involves human
judgement and so on. Alternatively, we looked also at what could be done without
reference to an external entity and you could see that if you just left it, you can mine as fast
as you want and a coin is 20 bits or something which was the default HashCash size a
million iterations of the hash. With Moores Law and increasing demand, you would have a
supply side inflation tracking Moores Law or worse, which we viewed as too violent to be a
practical adoption mechanism and conversely, if we put a cap as Beta Books, DigiCash Beta
Books experiment had of saying 1 million or 1 billion of these currency units, we would have
had violent deflation if we just started from there. Who would own them? If somebody
premined them all, definitionally and handed them out, that puts them in a position of
power. Alternatively, if you have free for all people mining, youd have a period of hyper
inflation followed by hyper deflation and we just viewed this as an untenable... if wed have
figured out a way to control that, there were lots of people there raring to go to implement
it but we just figured that this was uncontrollable and so not plausible as an adoption
mechanism. Curiously, one of the people that was participating in this discussion
anonymously seemed more interested to continue this line of thinking. His last post in the
thread was that this seems a very promising avenue that should be explored further.
Possibly, you could think that might have been Satoshi and hes been mulling it over ever
since and finally got around to working it out. [59:58]

AA: About a decade of mulling it over. [1:00:00]

AB: Who knows.... I guess, I heard indirectly that somebody said that he had said
approximately how long hed been working on it, maybe a couple of years or something so
maybe a period of mulling it over and some ideas emerging and then about two years of
implementation. The missing part we had there, back in 1998/9... and this thread is on the
Cypherpunks list; its still there. You can go look at it; its kind of interesting. *1:00:22+

AA: Its now the historical record for the birth of our new currency. [1:00:25]

AB: Ecash archaeology or something. The missing feature that we had there was how to
control this inflation so because of my asking the wrong question and looking for exactly $1
cost to mining, theres a downside to that which is an extremely inefficient method of
deployment. If you literally adopted that, which I was thinking about at the time actually,
and it went to global scale, we would basically burn a $1 trillion worth of coal to get a $1
trillion worth of (??) currency to operate with it. That would be a quite undesirable
outcome so I think Satoshis main big innovation was to come up with a mathematical
supply function which kind of solved three problems. Its an internal reference, its fully
decentralized, it achieves more efficient distribution because the electricity costs are much
lower. Even at this stage, now that we have mining, there is not actually that strong of an
incentive to go crazy and buy lots and lots of ASIC mining equipment because youll just
remove the profit motive. There is an equilibrium and the people that mined early on, they
did it for very negligible cost. They were lucky but they also produced an electrically
efficient distribution of electronic cash. The final thing that this mathematical supply
function created was a drive to adoption. Even though its a supply side inflation, its
experienced as deflation from the users point of view i.e. the coins that you hold going up in
value because the rate of adoption has exceeded the supply side inflation. The first four
years, 50% of coins were mined. Thats 12.5% a year. Now, were in a 6.25% a year and
after that, it will be going to 3.125%. Within three years, you can see the supply side
inflation is quite low and comparable to existing national currencies already. It seems that
the parameters of the system were very well chosen. Maybe with some very clever and
careful economic modelling or maybe with some luck and good guess work... educated
guess work. [1:02:12]

AA: Yes, obviously we know that now because it has worked and so we can say that the
parameters were well chosen but when it was first suggested, I think, a lot of people
pointed at it and laughed and said this cant possibly work which is probably the hallmark of
many good inventions in science. [1:02:28]

AB: I mean, its a really curious situation that I actually... the only bitcoins I own, I bought in
the market this year. I mined of a bitcoin on a GPU and my son has a couple of small ASIC
miners... my teenage son, at the moment, hes mining. I was aware of and participated in
this previous attempt to inflate the bubble. I was aware of Bitcoin like from September
2008 because Satoshi sent me an email and he sent me another email in January... so
September 2008; he sent me another email in January 2009 saying Ive released the alpha
version of Bitcoin, download it, try it out. I didnt (laughter). I sat outside the market and
sort of was... I mean, I was very interested technically in what hed achieved and I read,
with interest, Hal Finneys experiments in exploring how it worked, trying it out, asking
technical comments and engaging Satoshi and others in discussion of this in the crypto lists
and I participated in that myself. For whatever reason, the connection to the inflation or
the probability of the balloon inflating didnt catch me until I saw $100 and $1bn market cap
and I thought Oh, its happened. (Laughter) *1:03:39+

AA: Thats a relief because many of us missed a couple of iterations of that and felt really
dumb for not noticing it earlier and to know that someone who has been as influential in the
development of these technologies could also miss it. Its really one of those things that, in
theory, seems bizarre but then suddenly, when it gains the market traction, it all falls into
place. In hindsight, its very easy to say Well, yeah obviously this was the right way to do it
but thats really just observer bias. *1:04:45+

AB: You could say that I was dumber than everybody else because I had prior experience of
attempts to inflate a currency and I understood all the cryptography and the principles
involved and I had tried to design something similar in the past. I have trouble explaining it
to myself why I didnt but I think... [1:05:02]

AA: I think its harder for someone whos so involved in these things and also sees many of
the alternative options that could be chosen to see which one is the right one, whereas a lot
of the adoption we see right now is probably just speculative sentiment and has nothing to
do with understanding the fundamentals. In fact, the more you understand the
fundamentals, the more excited you are about how amazing it is that this is all working.
[1:05:25]

AB: As I recall it, its a few years now ago that I was thinking that I recognized it as a
bootstrap experiment obviously, and I thought thats an interesting bootstrap experiment
but, for some reason, it felt like it was a very big inflation job and the balloon was vast.
Thats to say that it was starting at a very tiny level and it had a very big area to reach so it
seemed quite low probability to reach it. In hindsight, thats not actually very much the
case. It had almost identical characteristics to the Beta Books, so anyway... Im not at all
bitter about it. I have skin in the game because I bought bitcoins with my own money. They
went up three times or something, at the moment. [1:06:06]

AA: Its still really early days and were still on the foothills so there is plenty of opportunity
to help form this new industry. [1:06:15]

AB: I wanted to say something also. Looking at it from the outside, you see when I was
exploring electronic cash, I had the background of looking at the cryptographic side where
they had all these advanced experimental protocols, so you see David Chaums ecash. David
Chaums a PhD student who is a friend of mine. Stefan Brands developed a much more
sophisticated form of electronic cash with many more features and flexibilities that these
things have cryptographic blinding which enables you to have mathematically perfect
fungibility. When I saw Bitcoin, I saw that it had a kind of fudge for its fungibility level so, to
my point of view that was not ideal. Potentially, if it had a more idealized fungibility layer, I
might have been more excited about its prospects. Now, obviously its very difficult to
achieve a distributed version because Stefan Brands technology and before him, David
Chaums technology are single server technologies or potentially, cluster of server you see
open transactions as a kind of federated model, where they have a semi-trustless group of
Chaum or other kind of centralized cash servers that can perform some kind of hybrid...
some interesting properties, less vulnerable to centralization risks as central server DigiCash
type servers but less decentralized than Bitcoin itself. Its actually quite technically
challenging to obtain cryptographic anonymity within Bitcoin and some of the esoteric
crypto-protocols for doing these things are experimental and it can be a risk, for when
theres real money at stake, to use very cutting edge, experimental crypto-protocols
because they may be broken in a period of 10 years. Even if theyve been around for 15
years, lets say, if theyve been esoteric and theres been no real reason to analyse them,
they might not actually have had that much work put into it but there was a protocol which
was compatible with distributed use which was a paper by Sander & Ta-Shma called
Auditable Electronic Cash which was published in 1999. That involves a zero knowledge
proof of set membership and the Zerocoin paper refers to that and Zerocoin is essentially an
optimization of the anonymous, auditable ecash. When I first saw Bitcoin, my immediate
thought was Well, you could have used Sander & Ta-Shmas auditable, anonymous
electronic cash protocol which fits perfectly with the network properties of this system and
would provide a perfect fungibility layer. Unfortunately, Sander & Ta-Shmas protocol is
somewhat computationally heavy and inefficient because it involves (??) cryptographic
proofs which involve multiple rounds and large messages and so on. You see that Zerocoin
has the same problems. Its an optimization but even with that optimization, its still almost
impractically inefficient. The coins are 20-40kB per coin, they have a single denomination so
typically lets say, you would need to have a one cent coin. If I want to send you $50, I have
to send you 5,000 times 40kB of data or I have to split the coins up into denominations, like
in powers of two, 1 cent, 2 cents, 4 cents heading up to 16,384 cents. By doing that, you
would reduce the anonymity set so you weaken the anonymity and still that would be a
significant expense. I do see desirability of having cryptographic anonymity and apparently
the guys at John Hopkins University, Matthew Green and colleagues, have a new paper that
is in the works. Theyve been making comments about that theyre going to publish it soon
so well see what that achieves. They claim to have achieved some much greater efficiency
and I guess not too much can be said about it yet because they havent formally published
it. I think the risks that it will face are to do with the type of crypto it uses. If its using very
cutting edge crypto, again, even if theyve solved largely the feature requirements of getting
the computational and space efficiency... I mean, as long as the verification efficiency is
reasonable, the creation efficiency... we can play with that somewhat; it doesnt matter so
much if thats somewhat computationally expensive or memory intensive or what have you.
In that circumstance, the problem is that if its involving experimental cryptography, you run
the risk that if you say OK, lets adopt this for Bitcoin... if somebody makes some new
group (??) attack or some mathematical attack over the next 5-10 years, it could be a
currency catastrophe of an economic global scale. [1:10:23]

AA: Right. At least we can somewhat trust the ECDSA to be thoroughly tested and rely on it
for decades. [1:10:31]

AB: In fact, its a curious fact that Bitcoin itself is using only very simple, conservative
cryptography and actually, I had some thoughts about the fungibility layer. Hypothetically,
if we had the desirable fungibility layer so if we had, lets say, Zerocoin 2; their paper say it
has ideal properties and lets say theres a Zerocoin 3 rather which... by the John Hopkins
authors or by any other authors... a cryptographically perfect fungibility layer which would
hide whos paying who, how much and avoid any anonymity set limitations so youd have
full anonymity set between all the holders of Bitcoin. In that circumstance, you have a quite
extreme form of anonymity; anonymous payment. One person can pay another person 1
cent or a billion dollars and theres nothing anybody can do about it ever to determine what
just happened and you cant trace it. *1:11:25+

AA: Cant see it, cant stop it, cant trace it. *1:11:27+

AB: There may be some limits to that which is it would typically be the case with an
anonymity protocol that the sender would keep a transcript or could keep a transcript and
so the sender may be able to retain a proof that he could reveal, in the case of subpoena, to
show who he sent it to. There could be some limited traceability but I think its entirely
possible also to build different privacy features. If you view the fungibility layer as about
fungibility, purely, which is to say that enforces that a dollar is a dollar and you dont get any
red listing or taint tracking attacks that effect transaction cost into fungibility layer. Above
that, we have a payment layer and (??) we have the Bitcoin payment protocol with
identification for the web server so you know youre paying the right person. I think the
correct place to manage identity is in the payment protocol layer and to keep the
transaction layer pure to avoid transaction cost leakage. You can add or manage all kinds of
different privacy layers and you have a lot of flexibility in it all using standard, very simple
cryptography at that layer, once you have the perfect cryptographic fungibility layer. For
example, you can use the existing Bitcoin self-chosen account number, pseudonym model
where you have an address that your computer has generated. You could choose to reuse
that address and actually, contrary to de facto advice from any Bitcoin clients, many Bitcoin
wallets reuse addresses which actually damages the fungibility layer as present. With
perfect fungibility, you could reuse the address just for convenience and what that would
mean is that if you paid one person, you paid another person and youd have a similar kind
of linkability that you have in the Bitcoin protocol at present, which could be visible or could
be encrypted between the users if thats arranged so that a user could be presented. A
business entity with business records could be presented with a subpoena to prove the
account numbers that it had transacted with, if somebody was trying to trace some funds
for some kind of crime related event. In your interactions with regulated businesses, you
could provide identity so for example, the analogy of going into a gun shop with a passport
proving youre eligible to own a gun in the United States and handing over cash over the
counter to pay for the gun; there is no identity attached to the cash, the identity is attached
to the transaction and showing the passport. [1:13:38]

AA: Right. [1:13:38]

AB: You see the same thing. You could do that with a regulated business using Bitcoin.
Actually, that was my objection to the red listing train of thinking is that you dont want to
extract that from the fungibility layer because you damage the fungibility layer. If you do
want to provide a facility to help people run regulated businesses, you provide some
mechanism for a digital drivers licence that smoothes the path to signing up to exchanges
where currently you have to fax them high resolution or scan and send them high resolution
scans of your utility bills and passport or what have you. You could have an electronic
version of that, thats validated by a registration authority in the same way that you have
certificates issued by a certification authority - a registration authority that verifies the
underlying documents and proofs. [1:14:20]

AA: The idea that somehow the only way to solve crime is to track everybodys money all
the time is insidious. Crime was solved before money was trackable and trackable money is
a recent invention. Somehow people managed to solve crime when a lot of transactions
were entirely in cash and we didnt need every bill tracked. Its really a new invention,
right? [1:14:45]

AB: Yes. Very much so. [1:14:47]

AA: Can we stop it? In Bitcoin, can we provide a fix that will solve this problem at a
protocol layer before it becomes implemented by government? [1:14:55]

AB: We have a number of best effort technologies and there are things we can do to
improve the fungibility layer within the scope of Bitcoin itself; I mean, with existing
protocols so encourage more Bitcoin wallets to not reuse addresses. As I understand it, the
Eligius pool is discouraging reuse addresses by prioritizing single use addresses, prioritizing
the processing of single use addresses. There is a protocol by Greg Maxwell called CoinJoin
which provides a kind of trustless way to improve fungibility so basically, there is some kind
of traceability in the Bitcoin network to do with change addresses and so on and the
CoinJoin protocol, which can be implemented in a server... and I understand Blockchain.info
has done that and maybe some other actors... and can also be implemented in the client,
which I think is an even more interesting place to put it. It can, basically, slightly enhance
the existing fungibility mechanism. I think people should understand that this is not
necessarily about achieving anonymity, its about retaining the value in Bitcoin. Bitcoins
value, in a large part I suspect, depends on the fungibility of the coin because otherwise the
transaction costs will rise to reach credit cards and then it no longer has a transactional
advantage. I think its in the interest of every significant holder of Bitcoin to ensure that we
draw a line in the sand and dont encourage or condone or make use of any systems which
try to encourage red listing and therefore damage fungibility. I view CoinJoin as a good,
practical, immediate step that can be taken and you see that also with the Darkwallet with
Amir Taaki and Vitalik Buterin and some other participants. Theyre implementing peer to
peer mediated CoinJoin within the Darkwallet clients of that and that will become the wallet
that most strongly strengthens fungibility which is good for Bitcoin. Once they get that
implemented, I would encourage other users to look at their innovation, in terms of the
peer to peer mechanism that they will have to develop to achieve that. [1:16:53]

AA: One of the things weve learned about practical application of cryptography tools and
privacy tools for a broad audience was that things that require technical expertise and
power users, like PGP email, never achieves mass scale but things that were on by default,
always on and in many cases without the users choice, like SSL, have been much more
effective at bringing mass adoption of these capabilities. Do you see the same issue with
CoinJoin? Do we really need to make this the default selection for every wallet so the user
is doing coin remixing whether they know it or not and every transaction is CoinJoined?
[1:17:31]

AB: Yes, I mean, I think until we have a stronger cryptographic solution that doesnt rely on,
potentially, risky, cutting edge crypto, thats the best we have. I dont really like to call it
mixing because I dont really view it about anonymity; I view it about fungibility. Theres still
tracking outside of that, in terms of people are interacting with websites at the payment
level. Theres still trackability at the payment level; at the TCP/IP level. TCP/IP addresses
are connectable to physical addresses and you can look up geolocation and ISPs retain logs
so theres very much trackability and identity involved in 99% of Bitcoin users who are not
bad actors, existing Bitcoin payment processors, merchants and so on. Really its not about
mixing which is a kind of anonymity term but its about a fungibility mechanism to
cryptographically enforce fungibility with this kind of... it is mixing technically, at a technical
level but its about retaining fungibility. *1:18:27]

AA: Yeah, so fungibility is one of the core principles that gives Bitcoin its strength. We
should not give up that capability and if we do so and if we fail to recognize the signs that
some of these perhaps misguided but well-meaning attempts to prevent fraud by modifying
the fungibility of the protocol, can ultimately have very destructive consequences on the
value of the currency by essentially, PayPalizing it or turning it into a credit card equivalent.
[1:18:57]

AB: I think any kind of identify management should happen at the payment level and weve
already got steps towards that with the payment protocol that Mike Hearn proposed and
theres a BIP and its being implemented. *1:19:10+

AA: BIP70, BIP71 for the payment protocol, yeah. [1:19:13]

AB: Right. Actually, the payment protocol itself provides a new privacy feature
independent from CoinJoin, which can be used in conjunction with it, which is that one of
the things that links transactions is the transaction amount. If addresses are not reduced,
the main thing that leaks it is the transaction amount and the change address, if the
transaction amount is unique. One thing you can do within the payment protocol is you can
request multiple addresses from the merchant, so if youre paying $10.95 for something,
you can pay $5 and $5 and build it up out of change that has more even values so that
makes it stand out less, in terms of looking at the Bitcoin transaction network which is the
change address and whether these two payments these two $5 payments are actually
involving the same user and the same merchant. If its done properly, that may not be so
obvious. [1:19:57]

AA: You dont need to combine many of your smaller inputs, thereby tainting them with
each other which would also reveal prior relationships between them, so theres another
layer to that. Thats very interesting. *1:20:08+

AB: At present, the Bitcoin wallets are not doing anything intelligent, in terms of their
change management. There is a feature called CoinControl which aims to make more
intelligent use of change to sort of minimize the number of change values within your wallet
because its pretty much when you combine... so if youve got 100 ten cents left over, as you
have your jar of change at home... if you start using that, in Bitcoin terms, thats what tends
to link your payments together. Can I just say something else about the tendency to think
that its necessary to put innovation into altcoins. I went through an evolution of thinking
about this when I first got deeply involved in understanding the Bitcoin limitations and
trying to help move them forward about six months ago, earlier this year. I thought that the
proposals could be, potentially, integrated into Bitcoin but, over time, I realized that the
Bitcoin core developers have this challenge we discussed earlier that they cant accept high
risk changes because theyve got to be so careful about testing, then you start to think
maybe you could put this in one of the altcoins. To do that presents a new risk to Bitcoin
which I think, potentially, the world can only really support one virtual scarce currency
because if one of the altcoins were hypothetically to reach parity with Bitcoin, firstly that
has no intrinsic value, which is a kind of dangerous position in itself but if, psychologically,
people jumped onto it... I say no intrinsic value because theres no transaction load in
there. If, hypothetically, people were to... Bitcoin holders, the speculative component of
Bitcoins value were to jump into this altcoin, you might see a Bitcoin price collapse and the
altcoin taking off. Maybe actual transactions moving to the network or transactions
happening via Bitcoin... sort of currency conversion from the alt to Bitcoin to the merchant
because Bitcoin also has all the infrastructure... but that once you had this kind of unhealthy
situation, you might see holders of this new altcoin looking nervously over their shoulder at
the next altcoin which was in a similar position with no intrinsic value but gaining value on it
speculatively. Basically, once people were to experience this kind of thing, it might say
Well, wait a minute, what does virtual scarcity mean, if everybody can come along and
propose some kind of parameter tweak or small functional change to get users interest, or
even the name, or affiliation with a celebrity or something like that. People might start to
question the very core principle of virtual scarce commodity. I think its really best to focus
on and stick with the one bootstrapped currency and I dont think its really a fair
proposition to go into an altcoin because now that its happened once, people are looking at
it as something that is much more plausible. Stating my dislike for that... theres a financial
risk there for the Bitcoin stability and long term viability of digital scarcity which I think is... I
think digital scarcity is a huge invention precisely that basically, Satoshi enabled with this
new innovation of controlled supply. I think it would be a very unfortunate end for Bitcoin,
if that were to collapse or be significantly weakened by a kind of speculative bubbles in
altcoins that were to start to compete with Bitcoin for market cap. [1:23:16]

Having stated that reservation, what do I propose that people could do about that? What I
propose is that they could put it in Bitcoin so we know that its challenging. I proposed a
way to put new features into Bitcoin without risking Bitcoin value. Basically, the way you do
that is you start a new altcoin... well call it Bitcoin 2. Bitcoin is currently on version 0.89
something so as with operating systems and other software packages, its quite common for
there to be a beta version. Its not an alpha version; its relatively stable. Its not going to
eat your data, lose your files or corrupt your computer so you put the features into the beta
version and theres development in parallel here. People are maintaining bug fixes, as in
Bitcoin, on the current stable version and theyre adding the missing features to the beta
version. You could view it as the way you see with Red Hat Fedora. Red Hat is extremely
well tested and enterprises can rely on it for rock steady service for important websites.
Fedora is adding new features all the time. Periodically, there will be a new major release of
Red Hat which pulls in the features from Fedora, stabilizes it and uses it. What I would like
to see for Bitcoin is for Bitcoin to adopt this development model and because its a currency,
there is a question of can you put value in the Fedora of Bitcoin Bitcoin 2? It turns out
there is a way to do that, while avoiding importing risk back into the main Bitcoin network.
What you can do is have a mathematical, one-way peg between Bitcoin and Bitcoin 2 which
is so youre allowed to move an existing bitcoin into the Bitcoin 2 network but the Bitcoin 2
network has no native reward mining. It would probably be merge-mined with Bitcoin and
by doing this there would be a market price to move the coins back. By doing it this way,
you preserve the 21 million coin promise; like that cap is maintained through the evolution
of features and through the move between major new features. You could imagine a
timeline of one year or eighteen months or whatever cycle makes sense for testing
resources available to move between these things. As it gets closer to the switch over time,
people would move coins over and you could algorithmically move the remaining coins over
and then start the process again and move forward in that way. [1:25:20]

AA: Its not just about how you implement the technology, its also how you implement the
currency infrastructure and the balance between maincoin, altcoin or, in this case, maincoin
and devcoin essentially, thats happened... the development coin or betacoin thats
happening to promote these new features. [1:25:41]

AB: Basically, its a rejection of the idea that you should push innovation into altcoins
because I view that as an existential risk to the very concept of digital scarcity as well as
being... I dont know... pure speculation. It also detracts from the Bitcoin mindshare and the
basic model. The interesting thing about having a one-way peg is that you cant introduce a
two-way peg because while youre being very careful on the Bitcoin 2, you are adding new
features. If something bad happens, despite the best efforts, you dont want that risk being
imported into Bitcoin. [1:26:10]

AA: Right. [1:26:11]

AB: Because there is a valve or one-way peg, if you want to go back into Bitcoin, you have
to buy it at market and if a vulnerability is discovered, until thats fixed, that market will
freeze up so therell be no risk to Bitcoin. *1:26:21+

AA: The price will diverge essentially. [1:26:23]

AB: Temporarily, until the itch is fixed, unless its a... yeah. *1:26:27+

AA: That provides enough friction to keep people in Bitcoin 2 allowing you the fix to happen
so that you can then recover that. [1:26:35]

AB: Yes. I think people... one worry people might have is to say that the technical
mechanism by which you move bitcoins into the Bitcoin 2 is technically... you destroy the
bitcoin and so they view that as somehow aesthetically unpleasing that youve destroyed
this beautiful rare number or something but actually, its just a technical mechanism to
move a coin. You can still verify that this is a mined coin when its been moved into the
other network. You look with a reference of where it came from and you look at the mining
event. As long as people can see a promise and timeline that the Bitcoin 2 network will
become the Bitcoin network within some approximate time length, they shouldnt have too
much reservation about putting money into it. You could see, in the short term, that if
somebody needs to move money back, or prefers to move money back after theyve used
the features in Bitcoin 2 for long term storage into the original network, that there might be
a mismatch between the market, so anybody who wants to move bitcoins into Bitcoin 2 can
do it by destroying a coin so theres no loss to them to accept a trade coming back the other
way. If theres a trade imbalance in the other direction, the coins could potentially sell
below par but I think, if theres an implied promise that it doesnt really matter if you just
wait another six months or something, all the coins are going to be equivalent because
theyre all going to be moving too... the bitcoins are going to move onto the next version
anyway, then it should combat any kind of extreme fluctuations. If there are fluctuations
with that implied promise there and if theres a significant discount, people will buy them to
hold them for the year, basically, because it will be an arbitrage opportunity with a quite
certain payout. Theres no counter party risk. [1:28:07]

AA: Its an ultimate merge of open source, as a development model and currencies and
there are some real intricacies in the management of that. [1:28:32]

AB: I just wanted to explore another payment privacy model which is... one thing that you
see in Bitcoin is that all the transaction values are public on the blockchain and... [1:28:43]

AA: That creates a risk for analysis of the values in order to break the privacy and (??)
[1:28:49]

AB: Thats very much true but there is another motivation which is, apart from like taint
analysis which is actually more to do with the chain of custody which is visible, but also the
transaction amounts provide a second attack on that. There is another layer so like more at
the business layer or something, that looking at the values flowing on the network, you have
to be careful using Bitcoin that you dont reveal your Bitcoin net worth by making a small
payment from a large denomination coin say if youre holding a lot of coins, maybe you
want to divide them up into small pieces so that you dont risk getting mugged if you pay
somebody 1 bitcoin and they can see. I saw somebody last week who had 500 bitcoins on
his phone which I think is an insane risk personally, knowing quite a lot about the security
and (??) base band processor on the phone is actually quite easy to hack. Once you have
control of the base band processor; hack over the air. The base band processor is just the
part that implements the geoSIM protocol and once you have control of the geoSIM and the
base band processor, you have route access to the application processor and can empty it of
bitcoins, basically, so dont do that. *1:29:53+

AA: Yeah. [1:29:55]

AB: Theres the concern about net worth analysis and some people are paid their salaries in
Bitcoin so they reveal their... people can go and look how much they earn, so its a kind of
violation of payment privacy and people wouldnt be comfortable if their credit card
statement was posted online in the same way and its basically what Bitcoin does. Also for
companies, its quite unattractive because any kind of Bitcoin eco-system company has to
be careful that their business model cant be reverse engineered by looking at their profit
margins and looking at their trade volume. Its all on the blockchain and can be explored.
People can get an idea which address is theirs just by using their service, even if they reuse
addresses, there is some linkability. [1:30:31]

AA: Some want open book accounting but this is open book accounting for everyone
whether they want it or not. [1:30:36]

AB: Going back to some early Cypherpunk ideas, Eric Hughes had proposed the idea of an
encrypted open book. It turns out that some of the encryption algorithms provide
homomorphic additions. Its relatively well known that dual homomorphic encryption,
where it supports addition and multiplication, is a kind of open problem. There finally, in
the last decade, have been a system that works but is phenomenally, impractically
expensive but in the realm of single homomorphic encryption where you can do addition
only or multiplication only or some variant of that, there are actually very efficient systems
to do that. [1:31:14]

AA: Just a quick explanation. Homomorphic encryption and the ability to do addition this
is where you get two encrypted inputs, you compute the output and you have no idea what
you just computed but the output can be valid and used by someone. [1:31:30]

AB: Exactly. If you have, lets say, $2 plus $5 getting combined and spent to a $7 payment,
if you have encrypted $2 and encrypted $5, you can actually test that that adds up to
encrypted $7, without knowing any of the amounts involved. You can use this principle on
the blockchain, say if you have encrypted values instead of the current 64bit plain text
values, you have encrypted values and you can have validation with value privacy, so its
really attractive for practical commercial use of Bitcoin because companies very much dont
want to expose their profit margins and so forth. Now, there is a technical problem with
straightforward homomorphic encryption otherwise it would actually be very efficient;
space efficient. The best thing is you can store that in about the size of a DSA signature or
something of that order which is very space efficient and quite practical but theres a
problem which is that the homomorphic encryption, the addition operation is that actually
modular the order of the group, which is a very large number N. Because of that, you can
cheat and you can add N to your balance by doing various things, so you have to defend
against that and that adds some complexity. There are conservative known crypto-
approaches to proving that it didnt wrap around so its basically called a zero knowledge
range proof. I spent quite a bit of time, a few months ago, optimizing zero knowledge range
proofs to enable encrypted values and I was able to get it down to about a kB per value but
thats still quite a bit bigger than 8 bytes plain text values but for high value commercial
transactions... [1:33:04]

AA: Is it worth the extra cost? [1:33:06]

AB: Yeah, I mean its a negligible cost if youre talking about $100,000 transaction or
$1,000,000 transaction or something where you need that kind of thing. We could see a
mixture of... and actually they are compatible... you can mix homomorphic values and plain
text values so the validation procedure can take unencrypted inputs and combine that and
check that it adds up to an unencrypted output, then youd be able to move money around
on the network and not really be able to see whats going on. Theres an additional kind of
curiosity which is I found that I could make an extended zero knowledge proof which
created a kind of extended version of CoinJoin. With CoinJoin, you need to collect people to
participate with you voluntarily to improve the fungibility. There is a signature concept
called a ring signature and CoinJoin is more like a multi-party signature where a group of
people get together and they sign a message together. A ring signature is that I personally
want to sign a signature but I want to make it ambiguous who authored this message and so
I can implicate, without any cooperation or agreement, other people as potential authors of
it using a ring signature. Using the zero knowledge proofs and homomorphic encrypted
value constructs together, I made something I called Ringcoin. The way that works is that
you can, basically, prove that of the inputs to this transaction, some of them are mine
because I know the private key and some of them are other peoples. The way that Im able
to claim other peoples value is that Im able to modify other peoples balances, apparently.
Apparent balances is that I can prove that either I know that coins private key, so Im
authorized to take value off it or that the amount that Im taking off it is an encrypted
version of zero. Thats of no possible damage to anybody for the network to allow me to
take zero off of hundreds of other people. That could potentially provide a more robust
fungibility. Unfortunately, the zero knowledge proof doubles in size from 1kB to 2kB where
you do that because the way you do zero knowledge all proofs, as a kind of basic
fundamental building block, involves basically doing things twice you have to cover both
halves of it. It basically doubles the zero knowledge proofs size but I was quite interested to
explore whether there was some way to make an even more compact ring proof where you
could basically have an anonymity set from a large number of coins, chosen at random, or
chosen specifically. A potential limitation with CoinJoin is that people could try to influence
the parties that you are joining with to reduce your anonymity set and therefore the
effectiveness of the fungibility improvement. [1:35:40]

AA: And the values are visible. [1:35:44]

AB: And the values are visible, of course. [1:35:45]

AA: Which is a big taint in traffic analysis risk. [1:35:48]

AB: It might be within the bounds of possibility that one could get a ring signature even
with Bitcoin using some kind of extended CoinJoin. I havent thought too much about that
but its an interesting thing to consider further but certainly with the ability to choose who
youre mixing your (??) to choose anonymously yourself is much more certain that nobody is
attacking the network sense to influence who youre joining with. If your adversary is all the
people youre joining with, you havent enhanced fungibility at all, in fact. If you can choose
them at random, like with a cryptographic random number generator, youre much more
confident that youve achieved some real fungibility improvement. Alternatively, you could
even selectively choose the people to be plausible individuals who might otherwise have
executed this transaction so, for example if its an exchange transaction, you might mix it
with other users of that same exchange or something like that. You could perhaps get even
more practical fungibility improvement by carefully choosing people that you mix with.
[1:36:52]

AA: It sounds like were still at the very early stages. I mean, Bitcoin has proven its
capability to survive as a currency and generate a lot of value for a lot of people but there is
so much more we can do within the protocol. Youve mentioned four different approaches
to improving the fungibility layer and creating anonymity and privacy within. Clearly, the
state of the art is progressing just as fast and this new theoretical development as Bitcoin is
progressing itself. [1:37:20]

AB: I think the important thing is to use conservative cryptography or if youre using
experimental cryptography to have a disaster recovery plan that doesnt result in loss of
funds. Maybe there is some scope within that. We do need to improve the fungibility layer,
if we possibly can - CoinJoin and possibly Ringcoin. Another thing I had discussed with Greg
Maxwell and others was to use a different signature algorithm so the ECDSA algorithm is a
slightly complicated version of the Schnorr algorithm. I believe the main reason that ECDSA
even came into existence was to work around the Schnorr pattern which has now expired.
The Schnorr algorithm is very much simpler and actually slightly more secure, more efficient
and very much more flexible so you can do blind signatures with it. You can do signatures
from a trusted hardware device like a Trezor, while blocking any subliminal channel. The
problem with a hardware device is you may not trust the hardware manufacturer and he
has the easy possibility with a DSA signature to hide information in the K value and
therefore leak the private key and steal your funds or trace you or what have you. Using a
Schnorr signature... [1:38:29]

AA: Like a deliberate example of what we saw with the Android bug where the K value
wasnt sufficiently random but, in this case, youre deliberately introducing a compromised
K. [1:38:39]

AB: Right. There are two things. What you mentioned about the Android, the device is
misuse or not following advice. Basically, people should be using deterministic DSA which
derives the K value deterministically from the message and the ECDSA private key is a well
known protocol and all Bitcoin clients should be using it as soon as possible. That obviates
the ongoing dependence on a random number generator. You only need random number
generation during the initial set up of your wallet to create the ECDSA private key. People
should be doing that and that would have avoided the Android problem and if you can take
random number generators during the initial stage only, you can have manual user entropy
input that can type on keyboard, move the mouse or what have you, speak into the
microphone or Android phone. Thats the way to tackle that problem. Now, in terms of
subliminal channel, its exactly as you said that somebody could... a malicious hardware
vendor could extract a private key and leak it. He has a subliminal channel over the
message that the user is sending and so any kind of off-line client and the only two ones we
have that Im aware of right now are Armory off-line client and the Trezor hardware wallet.
Using the Elliptic Curve Schnorr algorithm, there is a protocol which is... Im not sure if its
actually due to Brands, it may actually be earlier but it was certainly used to good effect by
Stefan Brands in his protocols. His electronic cash protocols have what he calls a wallet and
observer protocol, where you can have a subliminal channel free way to get a signature
from an embedded device. Basically, the way it works is you blind the message that you
want the device to sign and you provide a zero knowledge proof that the message inside the
blinded message is this cli text message. The device shows the cli text message, gets the
user approval, signs it, sends it back to the host computer and the host computer can then
unblind it, secure in the knowledge that, unless this (??) device has like a hidden wifi card in
it or something, there is no way... it has no communication path to the network. Thats a
more secure way of doing things. Also Schnorr signatures have other advantages in that
they are easy to make compact multi-signatures so with Bitcoin multi-sigs, you have a
separate signature for each signer which takes up space on the blockchain, so if you have
two or three signers, you have to have slots for those two signatures to go. With a Schnorr
signature, you can have a direct multi-party signature by two parties and the final signature
is of size of one signature and the public key of the signature is the addition of the two
signers public keys. It also supports simply K of N threshold signatures so you have two or
three and so on in the same model where the final signature is compact. I think, potentially,
even with no prior set up, so the users dont have to be part of a cooperative. You and I, if
wed never met before, we could get together and sign a two of two signature involving our
pre-existing public keys with value on them. Thats the Schnorr signature and some of these
features can have the potential to save space on the blockchain which is a valuable resource
and potentially to improve the fungibility mechanisms so for example, Greg Maxwell had
mentioned that he had some thoughts about using this kind of signature to make CoinJoin
more effective because there are some visibility of whats going on based on whos signing
so I think... I dont fully understand where he thought that could go but maybe he can figure
something out. There is certainly a lot more flexibility and a lot more possibilities from it.
Its more efficient, more secure and Dan Bernstein has proposed Schnorr signatures in a
new standard called EDDSA and I think its useful and possible that the Bitcoin network
could add that protocol, even incrementally and actually, they had been considering it for
independent reasons. Its more efficient as well. *1:42:20+

AA: This essentially means, not necessarily replacing ECDSA but allowing people the
possibility of using multiple different signature algorithms for the protection of their
outputs. [1:42:32]

AB: The EC Schnorr algorithm is more efficient computationally and could be much more
efficient space wise, in terms of blockchain bandwidth usage if multi-signatures start to
become widely used. I think for many of the more interesting, longer term features
involving smart contracts and so on, multi-signatures are more commonly used so that
could provide some value there. [1:42:57]

AA: Right. My guest has been Adam Back, applied cryptographer and very influential both
in the early history of digital cash but now increasingly helping us make Bitcoin better and
applying his cryptographic skills to improving the core fundamentals, including the
fungibility layers we discussed. Adam, thank you very much for joining our show. [1:43:16]

AB: Youre very welcome. *1:43:18+


____________________________________________


CREDITS:

Bitcoin with Adam Back was recorded and produced by Andreas M. Antonopoulos,
edited by Matthew Zipkin, with additional editing by Adam B. Levine. It featured
Adam Back and Andreas M. Antonopoulos
Music for this episode was provided by Jared Rubens, Calvin Henderson and
Matthew Murkowski

Questions or comments? Email adam@letstalkbitcoin.com.

Have a good one! [1:43:43]



_________________________________________