1
00:00:01,090 --> 00:00:03,460
The following content is
provided under a Creative

2
00:00:03,460 --> 00:00:04,850
Commons license.

3
00:00:04,850 --> 00:00:07,060
Your support will help
MIT OpenCourseWare

4
00:00:07,060 --> 00:00:11,150
continue to offer high-quality
educational resources for free.

5
00:00:11,150 --> 00:00:13,690
To make a donation or to
view additional materials

6
00:00:13,690 --> 00:00:17,650
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:17,650 --> 00:00:18,550
at ocw.mit.edu.

8
00:00:22,437 --> 00:00:24,770
TADGE DRYJA: Last class, I
talked about payment channels

9
00:00:24,770 --> 00:00:26,130
and lightning network.

10
00:00:26,130 --> 00:00:30,302
So today we'll talk a bit
more about payment channels.

11
00:00:30,302 --> 00:00:31,760
We'll recap a little
bit, and we'll

12
00:00:31,760 --> 00:00:36,210
talk about some optimizations,
one of which is key addition,

13
00:00:36,210 --> 00:00:37,910
the other is hash trees.

14
00:00:37,910 --> 00:00:40,430
And then we'll talk
about cross-chain swaps

15
00:00:40,430 --> 00:00:43,940
or cross-chain atomic swaps.

16
00:00:43,940 --> 00:00:49,060
OK, so last time, the sort
of main idea of these payment

17
00:00:49,060 --> 00:00:51,610
channels is you've got
this commitment transaction

18
00:00:51,610 --> 00:00:55,330
and each party holds a sort
of different transaction

19
00:00:55,330 --> 00:01:01,920
that has the same amounts but
slightly different scripts.

20
00:01:01,920 --> 00:01:07,050
So it's spending from a
shared funding transaction.

21
00:01:07,050 --> 00:01:09,270
And it's sending out to--

22
00:01:09,270 --> 00:01:12,430
the one that's held by
Alice on her hard drive

23
00:01:12,430 --> 00:01:14,730
sends to Bob in the clear.

24
00:01:14,730 --> 00:01:18,510
Bob just gets his eight coins
with no ifs, ands, or buts.

25
00:01:18,510 --> 00:01:20,670
However, when Alice
broadcasts this,

26
00:01:20,670 --> 00:01:23,580
she needs to wait 100 blocks.

27
00:01:23,580 --> 00:01:26,490
She needs to wait a day.

28
00:01:26,490 --> 00:01:29,550
And if she reveals
this key to Bob,

29
00:01:29,550 --> 00:01:33,030
now Bob can use Bob's key
in this revocable key,

30
00:01:33,030 --> 00:01:36,390
and Bob can get these
coins immediately.

31
00:01:36,390 --> 00:01:40,050
And the opposite is for Bob.

32
00:01:40,050 --> 00:01:43,575
So when Bob has his transaction,
it's got Alice's signature.

33
00:01:43,575 --> 00:01:45,450
He doesn't store his
own, because he can just

34
00:01:45,450 --> 00:01:47,960
compute it quickly.

35
00:01:47,960 --> 00:01:51,240
The two coins that go to
Alice go to her in the clear.

36
00:01:51,240 --> 00:01:54,720
However, the eight coins
that Bob gets for himself,

37
00:01:54,720 --> 00:01:56,310
he has to wait 100 blocks.

38
00:01:56,310 --> 00:02:01,820
And during the 100
blocks, Alice can

39
00:02:01,820 --> 00:02:06,540
sign if she has
Bob's revocation key.

40
00:02:06,540 --> 00:02:10,340
OK, so that's the basic
idea of these outputs.

41
00:02:10,340 --> 00:02:12,770
And then you construct these.

42
00:02:12,770 --> 00:02:16,220
So when I say, Alice, one
bitcoin, Bob, nine bitcoin,

43
00:02:16,220 --> 00:02:19,310
it's of the format in these.

44
00:02:19,310 --> 00:02:21,980
The person who holds
that transaction

45
00:02:21,980 --> 00:02:24,260
has a transaction where the
other party gets the coins

46
00:02:24,260 --> 00:02:28,910
immediately, and their own
coins have this lockup period,

47
00:02:28,910 --> 00:02:33,020
and can be grabbed by the other
party if they revoke them.

48
00:02:33,020 --> 00:02:37,912
So initially, the state is Alice
has one bitcoin, Bob has nine.

49
00:02:37,912 --> 00:02:39,870
There's two different
state 1 transactions, one

50
00:02:39,870 --> 00:02:42,150
held by Alice, one held by Bob.

51
00:02:42,150 --> 00:02:45,800
They build a new
transaction together

52
00:02:45,800 --> 00:02:49,020
where Alice has five coins
and Bob has five coins,

53
00:02:49,020 --> 00:02:54,750
and then they revoke the old
one by sharing these secrets.

54
00:02:54,750 --> 00:02:57,930
So now, since they both
have handed each other these

55
00:02:57,930 --> 00:03:03,610
revocation private keys, both of
these parties cannot broadcast

56
00:03:03,610 --> 00:03:04,110
this.

57
00:03:04,110 --> 00:03:08,170
If they do, the other
party takes all the money.

58
00:03:08,170 --> 00:03:11,420
And then you can build
these indefinitely.

59
00:03:11,420 --> 00:03:14,020
OK, so any questions about that?

60
00:03:14,020 --> 00:03:19,400
That was covered last time, but
it kind of can be complicated.

61
00:03:19,400 --> 00:03:19,900
Questions?

62
00:03:19,900 --> 00:03:20,400
Good?

63
00:03:22,750 --> 00:03:28,780
OK, so some optimizations
we'd want to make--

64
00:03:28,780 --> 00:03:31,880
yes, so basically, either party
broadcasts and has to wait.

65
00:03:31,880 --> 00:03:33,720
Alice gives Bob the
AliceR private key,

66
00:03:33,720 --> 00:03:35,540
Bob gives Alice the
BobR private key.

67
00:03:35,540 --> 00:03:37,110
If they broadcast,
the counterpart

68
00:03:37,110 --> 00:03:38,660
takes all the funds.

69
00:03:38,660 --> 00:03:40,310
So what are some
optimizations here?

70
00:03:40,310 --> 00:03:43,790
The basic idea of the
script is, OK, you

71
00:03:43,790 --> 00:03:45,830
can have a signature
from KeyA, and you

72
00:03:45,830 --> 00:03:49,010
have to wait a day, or
two, or five, or whatever.

73
00:03:49,010 --> 00:03:52,820
Or you can have a signature from
KeyB and a signature from KeyC.

74
00:03:55,690 --> 00:03:57,610
So what are some
optimizations here?

75
00:03:57,610 --> 00:04:01,120
The revealing part-- any
way to make that smaller,

76
00:04:01,120 --> 00:04:03,520
more efficient?

77
00:04:03,520 --> 00:04:09,300
So one idea is a pre-image
instead of a signature.

78
00:04:09,300 --> 00:04:11,670
You're just revealing
something, you're not actually

79
00:04:11,670 --> 00:04:13,450
committing to any data.

80
00:04:13,450 --> 00:04:16,470
So when Bob reveals his
secret, he could just be,

81
00:04:16,470 --> 00:04:18,089
here's a pre-image.

82
00:04:18,089 --> 00:04:20,820
And instead of like 70
bytes for a signature,

83
00:04:20,820 --> 00:04:23,895
you get down to like 20 bytes
for a hash and a pre-image.

84
00:04:27,620 --> 00:04:28,850
So how would it work?

85
00:04:28,850 --> 00:04:32,570
You'd just say, OK,
Alice signs if Alice

86
00:04:32,570 --> 00:04:36,860
knows BobR's pre-image.

87
00:04:36,860 --> 00:04:41,200
BobR doesn't have to actually
sign, she can just know it.

88
00:04:41,200 --> 00:04:43,860
That would work.

89
00:04:43,860 --> 00:04:46,350
So actually that was
the initial idea.

90
00:04:46,350 --> 00:04:49,770
I think that's what's
written in the paper.

91
00:04:49,770 --> 00:04:51,180
But you can do even smaller.

92
00:04:51,180 --> 00:04:55,660
So an even smaller way
to do it is combine keys.

93
00:04:55,660 --> 00:04:58,770
So in the elliptic
curve that we're

94
00:04:58,770 --> 00:05:01,770
using in all these groups,
all these signature schemes,

95
00:05:01,770 --> 00:05:04,670
if you add two keys together,
you can get a third key.

96
00:05:04,670 --> 00:05:07,260
And it's using the
addition operation

97
00:05:07,260 --> 00:05:09,840
that's defined on this group.

98
00:05:09,840 --> 00:05:13,560
So in the case where
you have KeyB and KeyC,

99
00:05:13,560 --> 00:05:15,660
and you add them together
to get, say, KeyR,

100
00:05:15,660 --> 00:05:18,250
what's the private key for KeyR?

101
00:05:18,250 --> 00:05:18,750
Anyone?

102
00:05:22,550 --> 00:05:26,160
You've got KeyB-- private key--

103
00:05:26,160 --> 00:05:29,390
KeyC, which has a private key,
you add the two public keys

104
00:05:29,390 --> 00:05:30,382
up together--

105
00:05:33,546 --> 00:05:36,500
yeah, it's the sum
of the private keys.

106
00:05:36,500 --> 00:05:40,230
So public KeyB is just private
KeyB times the generator

107
00:05:40,230 --> 00:05:46,520
point, G. But-- and then C
times G equals R times G.

108
00:05:46,520 --> 00:05:50,810
And then you can just move
the parentheses around.

109
00:05:50,810 --> 00:05:54,440
So B plus C, the private
keys added together

110
00:05:54,440 --> 00:05:57,840
times the generator
point is still the same.

111
00:05:57,840 --> 00:05:59,533
So this is a really
nice property.

112
00:05:59,533 --> 00:06:01,200
Actually, it's sort
of the main property

113
00:06:01,200 --> 00:06:05,250
that we use for all
signatures and all this stuff.

114
00:06:05,250 --> 00:06:11,790
What that means is you can say,
here, I take your public key,

115
00:06:11,790 --> 00:06:13,980
I'm going to come up
with my own private key,

116
00:06:13,980 --> 00:06:16,900
compute the public key for that,
add them together, and say,

117
00:06:16,900 --> 00:06:21,390
hey, we've got this
new shared public key.

118
00:06:21,390 --> 00:06:23,640
And neither of us
can sign with it

119
00:06:23,640 --> 00:06:26,187
yet because we don't know
each other's private keys.

120
00:06:26,187 --> 00:06:28,020
But if either of us
reveals the private key,

121
00:06:28,020 --> 00:06:30,240
then the other party
can sign with it.

122
00:06:30,240 --> 00:06:34,080
So if this is Bob's and
this is Alice's, they

123
00:06:34,080 --> 00:06:38,600
can both compute little r times
G by doing this operation.

124
00:06:38,600 --> 00:06:42,840
They both share public keys and
compute the shared public key.

125
00:06:42,840 --> 00:06:45,460
But they cannot sign, because
neither of them knows little r.

126
00:06:48,710 --> 00:06:53,293
And then let's say Alice says,
OK, Bob, here's this little c,

127
00:06:53,293 --> 00:06:53,960
gives it to Bob.

128
00:06:53,960 --> 00:06:56,360
Bob says, OK, now
I know a little r.

129
00:06:56,360 --> 00:06:59,240
But Alice doesn't.

130
00:06:59,240 --> 00:07:03,780
So this is a really
nice way to do it,

131
00:07:03,780 --> 00:07:05,250
because it saves a lot of space.

132
00:07:05,250 --> 00:07:09,240
So instead, the script
is now just KeyD--

133
00:07:09,240 --> 00:07:10,930
oh, I should have put R, oops.

134
00:07:10,930 --> 00:07:14,010
KeyD or KeyA and time.

135
00:07:14,010 --> 00:07:18,200
So instead of having
this key and time passes,

136
00:07:18,200 --> 00:07:20,420
or these other two
keys both sign,

137
00:07:20,420 --> 00:07:23,420
you just have a single key
that can sign immediately,

138
00:07:23,420 --> 00:07:28,260
or another key that can
sign after a period of time.

139
00:07:28,260 --> 00:07:32,360
So the actual
script used is this.

140
00:07:32,360 --> 00:07:37,850
You say OP_IF, the
KeyR, OP_ELSE, delay,

141
00:07:37,850 --> 00:07:41,495
OP_CHECKSEQUENCEVERIFY, OP_DROP,
then the KeyA, then the ENDIF,

142
00:07:41,495 --> 00:07:42,370
then the OP_CHECKSIG.

143
00:07:42,370 --> 00:07:44,030
So I'll walk through
this because it's

144
00:07:44,030 --> 00:07:45,710
a little confusing.

145
00:07:45,710 --> 00:07:48,990
The OP_IF takes an
item off the stack,

146
00:07:48,990 --> 00:07:50,395
and it's either true or false.

147
00:07:50,395 --> 00:07:51,770
So the first thing
you have to do

148
00:07:51,770 --> 00:07:54,600
is you have to indicate
which of these two paths

149
00:07:54,600 --> 00:07:56,210
you're going to use.

150
00:07:56,210 --> 00:07:59,270
Either you're going to
put KeyR on the stack,

151
00:07:59,270 --> 00:08:02,660
or you're going to put
this delay number, which

152
00:08:02,660 --> 00:08:05,810
is, say, 100 blocks, put
an OP_CHECKSEQUENCEVERIFY

153
00:08:05,810 --> 00:08:09,030
to verify that it has been
100 blocks since you created

154
00:08:09,030 --> 00:08:11,330
the transaction you're spending.

155
00:08:11,330 --> 00:08:13,370
And then you have
to drop the delay.

156
00:08:13,370 --> 00:08:14,870
This was to ensure
compatibility,

157
00:08:14,870 --> 00:08:16,580
since it's a soft fork.

158
00:08:16,580 --> 00:08:18,420
So old nodes would see this.

159
00:08:18,420 --> 00:08:21,500
Old nodes would see this,
they would see a no-op,

160
00:08:21,500 --> 00:08:25,590
and then they would see the drop
to get rid of this whole thing.

161
00:08:25,590 --> 00:08:28,400
So the old nodes
wouldn't see it at all.

162
00:08:28,400 --> 00:08:30,642
Then you have a KeyA
put on the stack,

163
00:08:30,642 --> 00:08:32,059
and then you end
the IF statement,

164
00:08:32,059 --> 00:08:33,500
and then you check signatures.

165
00:08:33,500 --> 00:08:35,059
So really the IF
statement is just

166
00:08:35,059 --> 00:08:41,340
determining which key gets
pushed onto the stack.

167
00:08:41,340 --> 00:08:43,200
And then after the
IF statement, there

168
00:08:43,200 --> 00:08:46,690
is a CHECKSIG to check the
signature from that key.

169
00:08:46,690 --> 00:08:50,400
So for example, if you're
using the revocation

170
00:08:50,400 --> 00:08:53,640
key, the key that has been
combined and revealed to you,

171
00:08:53,640 --> 00:08:57,800
you just put a 1 on the stack,
and then a signature from R.

172
00:08:57,800 --> 00:08:59,760
And then the OP_IF
results to true,

173
00:08:59,760 --> 00:09:03,450
so it executes this by just
pushing the key onto the stack.

174
00:09:03,450 --> 00:09:07,230
Then it executes OP_ELSE,
skips to OP_ENDIF,

175
00:09:07,230 --> 00:09:08,970
and then does OP_CHECKSIG.

176
00:09:08,970 --> 00:09:14,550
So basically you say 1, execute
OP_IF, KeyR, skip to CHECKSIG.

177
00:09:14,550 --> 00:09:17,960
So it's just, you need
to sign with this key.

178
00:09:17,960 --> 00:09:20,610
Or you say 0, and
signature from A.

179
00:09:20,610 --> 00:09:25,890
And then so the OP_IF takes
a 0, it skips to OP_ELSE

180
00:09:25,890 --> 00:09:33,870
because it's not true, it
pushes delay onto the stack,

181
00:09:33,870 --> 00:09:36,690
performs CHECKSEQUENCEVERIFY to
make sure that enough time has

182
00:09:36,690 --> 00:09:40,160
passed, drops the delay
number off the stack,

183
00:09:40,160 --> 00:09:41,910
which is a little
ugly-- it would be nicer

184
00:09:41,910 --> 00:09:46,530
if OP_CHECKSEQUENCEVERIFY did
that itself, but it doesn't--

185
00:09:46,530 --> 00:09:52,380
then pushes KeyA onto the
stack, ends the IF statement,

186
00:09:52,380 --> 00:09:54,120
and checks the signature.

187
00:09:54,120 --> 00:09:56,280
So it's a little
more complicated

188
00:09:56,280 --> 00:10:01,770
than in C, where you just can
say, KeyD or KeyA and time.

189
00:10:01,770 --> 00:10:04,110
But this is stack-based.

190
00:10:04,110 --> 00:10:08,370
And it's not too hard when
you get these things to work.

191
00:10:08,370 --> 00:10:12,690
So any questions
about this setup?

192
00:10:12,690 --> 00:10:13,420
Yes.

193
00:10:13,420 --> 00:10:15,510
AUDIENCE: So what's
OP_DROP again?

194
00:10:15,510 --> 00:10:17,880
TADGE DRYJA: OP_DROP takes
the topmost item on the stack

195
00:10:17,880 --> 00:10:23,400
and deletes it, and all the
lower items come back up.

196
00:10:23,400 --> 00:10:26,910
Yeah, it's just so that,
compatibility-wise--

197
00:10:26,910 --> 00:10:28,470
there would be ways to--

198
00:10:30,990 --> 00:10:32,690
since OP_CHECKSEQUENCEVERIFY
basically,

199
00:10:32,690 --> 00:10:35,280
this used to be a no-op
where it did nothing.

200
00:10:35,280 --> 00:10:39,090
And then the soft fork was,
OK, we're redefining no-op 3,

201
00:10:39,090 --> 00:10:41,790
I believe, to
OP_CHECKSEQUENCEVERIFY, where

202
00:10:41,790 --> 00:10:46,680
it looks at, basically,
the age of your inputs,

203
00:10:46,680 --> 00:10:49,650
and how many confirmations
your inputs have had,

204
00:10:49,650 --> 00:10:53,670
or really the specific input
you're spending in this case.

205
00:10:53,670 --> 00:10:55,680
Old nodes would just
see it as a no-op,

206
00:10:55,680 --> 00:10:59,220
and so you could put
something like delay,

207
00:10:59,220 --> 00:11:01,500
OP_CHECKSEQUENCEVERIFY,
and then an OP code

208
00:11:01,500 --> 00:11:05,070
around here that says, make
sure the top item on the stack

209
00:11:05,070 --> 00:11:07,200
is greater than 5.

210
00:11:07,200 --> 00:11:09,840
And if this consumed
the delay value

211
00:11:09,840 --> 00:11:12,630
by taking it off the
stack, the old nodes

212
00:11:12,630 --> 00:11:14,130
might say, oh, this isn't valid.

213
00:11:14,130 --> 00:11:19,800
Even though this is a no-op,
the subsequent OP code

214
00:11:19,800 --> 00:11:21,120
causes this to fail.

215
00:11:21,120 --> 00:11:23,400
Whereas in the new
version, it would be like,

216
00:11:23,400 --> 00:11:26,580
no, this is good because
this consumes that value.

217
00:11:26,580 --> 00:11:29,340
And that would actually make it
a hard fork, because then there

218
00:11:29,340 --> 00:11:32,040
would be transactions
where the old nodes thought

219
00:11:32,040 --> 00:11:35,940
it was not good and the new
nodes thought, yes, this is OK.

220
00:11:35,940 --> 00:11:40,650
So to ensure that
this only restricts

221
00:11:40,650 --> 00:11:45,120
the validity of scripts,
it doesn't pop that off.

222
00:11:45,120 --> 00:11:47,040
So you have to manually drop it.

223
00:11:47,040 --> 00:11:48,480
And DROP is there from before.

224
00:11:48,480 --> 00:11:52,247
So to an old node, it would
say delay, no OP_DROP.

225
00:11:52,247 --> 00:11:54,330
And it's like, OK, you put
something in the stack,

226
00:11:54,330 --> 00:11:58,230
you do nothing, and then you
take it off the stack-- fine.

227
00:11:58,230 --> 00:12:00,530
So that's just a
compatibility thing.

228
00:12:00,530 --> 00:12:02,280
If you were going to
make it from scratch,

229
00:12:02,280 --> 00:12:04,670
you'd probably do
it differently.

230
00:12:04,670 --> 00:12:06,670
Other questions about this?

231
00:12:06,670 --> 00:12:08,325
OK, cool.

232
00:12:13,240 --> 00:12:14,800
So then you reveal keys.

233
00:12:14,800 --> 00:12:21,040
You keep revealing things each
time you make a new state.

234
00:12:21,040 --> 00:12:24,432
And you can do these
several times a second.

235
00:12:24,432 --> 00:12:26,640
You can do it 10 times a
second, something like that.

236
00:12:26,640 --> 00:12:28,120
So you can have
millions, billions

237
00:12:28,120 --> 00:12:29,740
of different old transactions.

238
00:12:29,740 --> 00:12:31,930
The problem is, you
do have to remember

239
00:12:31,930 --> 00:12:35,710
all of these old private keys
that your counterparty has

240
00:12:35,710 --> 00:12:36,640
given to you.

241
00:12:36,640 --> 00:12:41,008
Because if you forget one, they
might broadcast a transaction

242
00:12:41,008 --> 00:12:43,300
where you really need to know
that private key in order

243
00:12:43,300 --> 00:12:45,310
to grab the money immediately.

244
00:12:45,310 --> 00:12:50,020
So for example, you forget--

245
00:12:50,020 --> 00:12:54,160
this was revoked, but you forgot
about it, and you're Alice,

246
00:12:54,160 --> 00:12:55,713
and then Bob broadcasts this.

247
00:12:55,713 --> 00:12:57,380
You really need to
know that private key

248
00:12:57,380 --> 00:13:03,040
so you can grab Bob's five
coins with your combined key.

249
00:13:03,040 --> 00:13:06,720
So you need to keep track of
all of these little things.

250
00:13:06,720 --> 00:13:08,220
So it's 32 bytes each.

251
00:13:08,220 --> 00:13:10,050
It's not great for scalability.

252
00:13:10,050 --> 00:13:12,150
So there's actually a
couple of different ways

253
00:13:12,150 --> 00:13:12,900
you could do this.

254
00:13:12,900 --> 00:13:18,830
How can you remember a
chain of 32-byte secrets?

255
00:13:18,830 --> 00:13:23,110
A merkle tree itself would
have a root here, and then

256
00:13:23,110 --> 00:13:30,050
a bunch of little hashes that
go up to the tree's root.

257
00:13:30,050 --> 00:13:32,170
So if these were secrets--

258
00:13:32,170 --> 00:13:33,460
you can't go back down, right?

259
00:13:33,460 --> 00:13:37,540
So if you're like, OK, I got
secret 0, secret 1, secret 2,

260
00:13:37,540 --> 00:13:40,420
secret 3, well, I've got the
parents of these two things,

261
00:13:40,420 --> 00:13:43,180
but I can't actually
remember them any better.

262
00:13:43,180 --> 00:13:45,580
So a real simple way--

263
00:13:45,580 --> 00:13:47,430
say, OK, I've got--

264
00:13:47,430 --> 00:13:49,240
and you can construct
it however you want.

265
00:13:49,240 --> 00:13:51,282
Obviously if your counterparty
is not cooperating

266
00:13:51,282 --> 00:13:54,520
and these secret numbers
are just completely random,

267
00:13:54,520 --> 00:13:55,930
there's nothing you can do.

268
00:13:55,930 --> 00:13:57,722
If he just says, hey,
I'm going to give you

269
00:13:57,722 --> 00:13:59,740
secret 0, secret 1,
secret 2, there's

270
00:13:59,740 --> 00:14:02,620
no special properties
about these things.

271
00:14:02,620 --> 00:14:04,270
I can't do anything.

272
00:14:04,270 --> 00:14:06,790
The simplest way-- what's
a real simple way to say,

273
00:14:06,790 --> 00:14:09,730
OK, I'm going to reveal
secrets sequentially,

274
00:14:09,730 --> 00:14:11,560
and then you can
store fewer of them?

275
00:14:19,830 --> 00:14:22,382
It's sort of like a
blockchain, right?

276
00:14:22,382 --> 00:14:23,620
[CHUCKLING]

277
00:14:23,620 --> 00:14:30,750
So you could just say, OK,
well, I create secret 3.

278
00:14:30,750 --> 00:14:35,210
Secret 2 is the
hash of secret 3.

279
00:14:35,210 --> 00:14:39,860
Secret 1 is the
hash of secret 2.

280
00:14:39,860 --> 00:14:42,920
And so now I reveal 1.

281
00:14:42,920 --> 00:14:45,050
You don't know what
2 is, and so on.

282
00:14:45,050 --> 00:14:47,990
So 0 equals hash of 1.

283
00:14:47,990 --> 00:14:51,140
So you could just
have a linear chain,

284
00:14:51,140 --> 00:14:54,260
like this, so 0, 1, 2, 3.

285
00:14:54,260 --> 00:14:57,830
If you remember 3, you can
compute 2, and 1, and 0.

286
00:14:57,830 --> 00:15:01,250
If you remember 2, you can
compute 1 and 0, but not 3.

287
00:15:01,250 --> 00:15:02,955
So you can do that.

288
00:15:02,955 --> 00:15:04,580
That would actually
probably work fine.

289
00:15:04,580 --> 00:15:07,490
But we always want to
make unnecessary complex

290
00:15:07,490 --> 00:15:09,860
optimizations to things.

291
00:15:09,860 --> 00:15:13,280
So the problem with this is if
you've got a billion of them,

292
00:15:13,280 --> 00:15:16,550
and you need to go
back to the first one,

293
00:15:16,550 --> 00:15:20,280
you need to compute a
billion hash operations.

294
00:15:20,280 --> 00:15:21,530
That's kind of slow.

295
00:15:21,530 --> 00:15:24,770
So what we do--
or the basic idea,

296
00:15:24,770 --> 00:15:26,390
there's multiple
implementations,

297
00:15:26,390 --> 00:15:27,800
slight variations--

298
00:15:27,800 --> 00:15:29,090
you have a hash tree.

299
00:15:29,090 --> 00:15:30,680
So you reveal secrets
one at a time,

300
00:15:30,680 --> 00:15:32,720
you store only log(n)
secrets, and you

301
00:15:32,720 --> 00:15:37,210
re-compute any secret you want
with something around log(n)

302
00:15:37,210 --> 00:15:39,020
operations.

303
00:15:39,020 --> 00:15:40,070
I called it Elkrem.

304
00:15:40,070 --> 00:15:42,050
I think there's an
actual paper that

305
00:15:42,050 --> 00:15:43,810
basically is this, called GGM.

306
00:15:43,810 --> 00:15:47,860
And that's, I think,
written by people at MIT.

307
00:15:47,860 --> 00:15:50,110
But I called it Elkrem because
it's basically a merkle

308
00:15:50,110 --> 00:15:51,800
tree backwards, because
the arrows point

309
00:15:51,800 --> 00:15:54,690
the other direction.

310
00:15:54,690 --> 00:15:57,980
So in this case, you
start with a route-- you

311
00:15:57,980 --> 00:16:02,640
start with something up here.

312
00:16:02,640 --> 00:16:05,220
And you say, OK, if I
wanted to send to the left,

313
00:16:05,220 --> 00:16:09,630
I append a 0 to the
hash value of this root,

314
00:16:09,630 --> 00:16:11,550
and I hash to get that one.

315
00:16:11,550 --> 00:16:14,700
And if I want to go right,
I append a 1 at the end,

316
00:16:14,700 --> 00:16:16,980
hash that, and then
I go down here.

317
00:16:16,980 --> 00:16:19,160
So what that lets you do is--

318
00:16:19,160 --> 00:16:21,010
there is a sender
and a receiver.

319
00:16:21,010 --> 00:16:24,810
The sender just computes
a route, and stores that.

320
00:16:24,810 --> 00:16:27,045
They make a random
route up, store it,

321
00:16:27,045 --> 00:16:28,420
and then they also
keep track of,

322
00:16:28,420 --> 00:16:31,020
OK how many secrets
have I given?

323
00:16:31,020 --> 00:16:35,160
The receiver just receives
the first one, number 0--

324
00:16:35,160 --> 00:16:37,220
can't do anything.

325
00:16:37,220 --> 00:16:38,720
They receive 1.

326
00:16:38,720 --> 00:16:41,000
OK, still can't do anything.

327
00:16:41,000 --> 00:16:42,470
They receive 2.

328
00:16:42,470 --> 00:16:44,930
Now they can say, OK, well
I can throw away 0 and 1,

329
00:16:44,930 --> 00:16:48,140
because if I want to compute
0 and 1, I can just store 2.

330
00:16:48,140 --> 00:16:49,880
And if I want them
to send to the left,

331
00:16:49,880 --> 00:16:53,340
append to zero, and hash if
I want to send to the right--

332
00:16:53,340 --> 00:16:56,680
So I don't store
these, but I know

333
00:16:56,680 --> 00:16:58,660
they're still computable
for me if I ever

334
00:16:58,660 --> 00:17:01,030
want to grab them back.

335
00:17:01,030 --> 00:17:02,640
I receive 3, can't do anything.

336
00:17:02,640 --> 00:17:06,010
I receive 4, can't do anything.

337
00:17:06,010 --> 00:17:10,450
I receive 5, now I can do
the same thing with 3 and 4,

338
00:17:10,450 --> 00:17:15,130
remove those from the disk,
and only store 2 and 5.

339
00:17:15,130 --> 00:17:18,220
So if I get a request for
3, I can easily compute it.

340
00:17:18,220 --> 00:17:21,160
And then I receive 6, and I
can delete those two as well.

341
00:17:21,160 --> 00:17:24,160
So as I go up the
tree, sometimes I only

342
00:17:24,160 --> 00:17:25,869
have to store one
thing, sometimes

343
00:17:25,869 --> 00:17:29,272
I have to store three
things, because that's

344
00:17:29,272 --> 00:17:30,230
the height of the tree.

345
00:17:30,230 --> 00:17:34,540
Well, it's basically you
have to store at most one

346
00:17:34,540 --> 00:17:37,540
on every level, and
then sometimes two

347
00:17:37,540 --> 00:17:39,070
if there are two leaves.

348
00:17:39,070 --> 00:17:42,910
So basically log(n) storage,
and computing hashes

349
00:17:42,910 --> 00:17:44,300
is pretty quick, too.

350
00:17:44,300 --> 00:17:47,740
So that's a fun way
to only have to store

351
00:17:47,740 --> 00:17:50,170
a very small amount of data.

352
00:17:50,170 --> 00:17:52,080
Any questions about this?

353
00:17:52,080 --> 00:17:53,170
OK, so we're going quick.

354
00:17:56,326 --> 00:17:57,880
[INAUDIBLE] quick.

355
00:17:57,880 --> 00:18:00,890
OK, so we'll talk about
cross-chain swaps for most

356
00:18:00,890 --> 00:18:03,080
of the bulk of this day.

357
00:18:03,080 --> 00:18:06,580
So there are altcoins.

358
00:18:06,580 --> 00:18:07,930
I mostly work on Bitcoin.

359
00:18:07,930 --> 00:18:09,350
I think a lot of the
research is on Bitcoin.

360
00:18:09,350 --> 00:18:11,100
But there's a lot of
different coins, too.

361
00:18:11,100 --> 00:18:16,297
People saw the idea of Bitcoin
and said, hey, let's copy it.

362
00:18:16,297 --> 00:18:18,130
So initially, most of
them were just copies.

363
00:18:20,670 --> 00:18:22,590
There was a site
called coingen.io.

364
00:18:22,590 --> 00:18:25,530
So like 2012,
there started to be

365
00:18:25,530 --> 00:18:30,000
a lot of all coins, like
Litecoin, and Dogecoin,

366
00:18:30,000 --> 00:18:31,270
and things like that.

367
00:18:31,270 --> 00:18:33,990
And most of them were
real small changes,

368
00:18:33,990 --> 00:18:37,318
where they took the Bitcoin
source code on GitHub,

369
00:18:37,318 --> 00:18:39,360
and they changed a couple
numbers here and there,

370
00:18:39,360 --> 00:18:41,940
and they said, OK,
well, it's a new coin.

371
00:18:41,940 --> 00:18:45,480
And then BlueMatt made a site
called coingen.io, where you

372
00:18:45,480 --> 00:18:46,950
could do it all very easily.

373
00:18:46,950 --> 00:18:49,560
For people who weren't
programming-savvy,

374
00:18:49,560 --> 00:18:52,530
they could just make their
own altcoin by menus.

375
00:18:52,530 --> 00:18:55,500
There's a website, you say, I
want it to be called Tadgecoin,

376
00:18:55,500 --> 00:18:59,220
I want there to be 25
coins every three minutes,

377
00:18:59,220 --> 00:18:59,790
and I want--

378
00:18:59,790 --> 00:19:01,853
you know, just a
bunch of things.

379
00:19:01,853 --> 00:19:03,270
You could upload
a little picture,

380
00:19:03,270 --> 00:19:09,470
and it would make a program
for you based on those things.

381
00:19:09,470 --> 00:19:11,010
And then I think
he sold the site.

382
00:19:11,010 --> 00:19:14,440
I think it was the first
blockchain technology company,

383
00:19:14,440 --> 00:19:15,560
as far as I'm concerned.

384
00:19:15,560 --> 00:19:18,960
OK, so then recent ones
are very different.

385
00:19:18,960 --> 00:19:21,450
People trade altcoins
for bitcoins,

386
00:19:21,450 --> 00:19:24,810
and trade altcoins for altcoins,
and they use exchanges.

387
00:19:24,810 --> 00:19:26,420
I don't know if--

388
00:19:26,420 --> 00:19:30,160
have people here used
exchanges to trade altcoins?

389
00:19:30,160 --> 00:19:31,150
Some.

390
00:19:31,150 --> 00:19:32,230
I actually have.

391
00:19:32,230 --> 00:19:34,100
I hadn't until last year.

392
00:19:34,100 --> 00:19:38,320
But there was these
sort of hard forks

393
00:19:38,320 --> 00:19:40,540
from Bitcoin, like Bitcoin
Cash, and Bitcoin Gold,

394
00:19:40,540 --> 00:19:41,415
and Bitcoin whatever.

395
00:19:41,415 --> 00:19:43,510
And so I actually
opened an account,

396
00:19:43,510 --> 00:19:45,150
and sold them, and
got more Bitcoins.

397
00:19:45,150 --> 00:19:45,892
[CHUCKLING]

398
00:19:45,892 --> 00:19:46,600
How do you trade?

399
00:19:46,600 --> 00:19:48,730
Well, you use an exchange.

400
00:19:48,730 --> 00:19:50,920
And so the current
exchange model,

401
00:19:50,920 --> 00:19:54,730
pretty much without fail,
is give us all your coins,

402
00:19:54,730 --> 00:19:57,760
post orders on our site
to swap with other users,

403
00:19:57,760 --> 00:20:00,600
and then ask for
your coins back.

404
00:20:00,600 --> 00:20:04,680
So the "give us all your
coins" part, it works fine.

405
00:20:04,680 --> 00:20:07,500
They give you an address,
you send your coins

406
00:20:07,500 --> 00:20:10,650
to their address, and
it'll appear on their site,

407
00:20:10,650 --> 00:20:11,500
generally.

408
00:20:11,500 --> 00:20:14,100
But you definitely
can send your coins.

409
00:20:14,100 --> 00:20:18,690
The "ask for your coins back" is
where the model tends to fail.

410
00:20:18,690 --> 00:20:24,450
There's many, many cases where
they don't give them back.

411
00:20:24,450 --> 00:20:28,380
And there's a lot
of reasons for this.

412
00:20:28,380 --> 00:20:29,160
So Mt.

413
00:20:29,160 --> 00:20:32,070
Gox was one of the most
prominent early ones,

414
00:20:32,070 --> 00:20:36,360
but it certainly
wasn't the first.

415
00:20:36,360 --> 00:20:38,540
Probably one of the first
was called MyBitcoins.com.

416
00:20:38,540 --> 00:20:40,590
And then it was sort of--

417
00:20:40,590 --> 00:20:42,300
I don't know if it
was intentional,

418
00:20:42,300 --> 00:20:45,184
but the joke, after, was like,
well, it's his bitcoins now.

419
00:20:45,184 --> 00:20:46,546
[CHUCKLING]

420
00:20:47,820 --> 00:20:50,910
It was more of a web wallet
that had private keys

421
00:20:50,910 --> 00:20:52,290
than an actual exchange.

422
00:20:52,290 --> 00:20:54,810
But a lot of these exchanges--

423
00:20:54,810 --> 00:20:56,910
they're really easy to set up.

424
00:20:56,910 --> 00:21:00,240
You just write some
software, and people

425
00:21:00,240 --> 00:21:01,380
start sending you coins.

426
00:21:01,380 --> 00:21:04,110
And then either there's
internal problems

427
00:21:04,110 --> 00:21:06,240
where you've got
some rogue employee,

428
00:21:06,240 --> 00:21:08,670
or the rogue employee
is the only employee,

429
00:21:08,670 --> 00:21:12,240
and someone just realizes, hey,
this computer in front of me

430
00:21:12,240 --> 00:21:15,560
has $20 million
worth of stuff on it.

431
00:21:15,560 --> 00:21:20,370
I think I'll just unplug
it and keep all the money.

432
00:21:20,370 --> 00:21:21,890
Also hackers, right?

433
00:21:21,890 --> 00:21:23,670
They're probably
the best targets

434
00:21:23,670 --> 00:21:26,850
for trying to intrude
and hack into a system

435
00:21:26,850 --> 00:21:27,600
that you can find.

436
00:21:27,600 --> 00:21:30,060
Because there's a whole ton
of money on this computer.

437
00:21:30,060 --> 00:21:34,680
It's not like data or, oh, I
get someone's Facebook pictures

438
00:21:34,680 --> 00:21:36,820
or I get someone's
credit card numbers.

439
00:21:36,820 --> 00:21:41,020
Yeah, that's nice, but
bitcoins are sort of money,

440
00:21:41,020 --> 00:21:42,110
and you just steal them.

441
00:21:42,110 --> 00:21:45,067
OK, so other problems
with the exchange model

442
00:21:45,067 --> 00:21:46,650
is that people tend
to trust it a lot,

443
00:21:46,650 --> 00:21:48,420
and they think, well, this is--

444
00:21:48,420 --> 00:21:51,660
they assume that
it's like a bank,

445
00:21:51,660 --> 00:21:54,418
and banks are very trustworthy,
because in recent memory

446
00:21:54,418 --> 00:21:56,460
there haven't really been
bank failures, at least

447
00:21:56,460 --> 00:21:57,127
in this country.

448
00:21:57,127 --> 00:22:01,630
So they sort of carry that trust
forward, and bad things happen.

449
00:22:01,630 --> 00:22:03,090
So the idea is,
wouldn't it be cool

450
00:22:03,090 --> 00:22:05,910
if we could have
cross-chain swaps, where

451
00:22:05,910 --> 00:22:09,600
we have some kind of way where,
I've got a bunch of coinA,

452
00:22:09,600 --> 00:22:12,180
you've got a bunch of
coinB, and we can swap

453
00:22:12,180 --> 00:22:16,110
between them without giving
custody to some third party

454
00:22:16,110 --> 00:22:18,580
or even giving
custody to each other.

455
00:22:18,580 --> 00:22:22,620
So you can do this using Hash
Time Locked Contracts, just

456
00:22:22,620 --> 00:22:24,270
like in the Lighting Network.

457
00:22:24,270 --> 00:22:27,960
So you get this coin if and
only if I get this other coin.

458
00:22:27,960 --> 00:22:30,180
You want them to be atomic.

459
00:22:30,180 --> 00:22:33,180
Even if it's very quick, you
don't want any period of time

460
00:22:33,180 --> 00:22:38,590
in which one party has all the
assets or more of the assets.

461
00:22:38,590 --> 00:22:40,450
So the interesting
thing about this

462
00:22:40,450 --> 00:22:43,870
is the Lightning Network
sort of does this already.

463
00:22:43,870 --> 00:22:48,130
The Lightning Network is a
way to make atomic payments

464
00:22:48,130 --> 00:22:49,532
between different channels.

465
00:22:49,532 --> 00:22:51,490
And then if you look at
these channels and say,

466
00:22:51,490 --> 00:22:55,260
well, do the channels have
to be on the same coin,

467
00:22:55,260 --> 00:22:57,010
do they have to be in
the same blockchain?

468
00:22:57,010 --> 00:22:58,930
And basically, no,
not much difference

469
00:22:58,930 --> 00:23:04,100
has to happen for them to
be different blockchains.

470
00:23:04,100 --> 00:23:08,120
OK, so this is the HTLC
slide from last time.

471
00:23:08,120 --> 00:23:11,980
It's similar in that you have
these two outputs, the same as

472
00:23:11,980 --> 00:23:15,730
in a regular lightning payment
channel that's at rest.

473
00:23:15,730 --> 00:23:19,450
So for example, Bob holds this,
where if he broadcasts this,

474
00:23:19,450 --> 00:23:21,910
Alice gets two coins
right off the bat,

475
00:23:21,910 --> 00:23:29,170
Bob needs to wait 100 blocks, or
Alice can know Bob's revocation

476
00:23:29,170 --> 00:23:32,830
key, and she can get seven coins
or he gets the seven coins.

477
00:23:32,830 --> 00:23:35,290
And then you've got this HTLC,
Hash Time Locked Contract,

478
00:23:35,290 --> 00:23:41,130
where Alice needs to a
pre-image [INAUDIBLE]..

479
00:23:41,130 --> 00:23:46,750
Well, yeah, Alice needs to
know R, this receipt, or Bob

480
00:23:46,750 --> 00:23:48,220
has to wait.

481
00:23:48,220 --> 00:23:53,500
But the difference in waiting
is this is a relative time lock,

482
00:23:53,500 --> 00:23:58,630
so that Bob has to wait 100
blocks after he broadcasts

483
00:23:58,630 --> 00:24:00,940
this transaction.

484
00:24:00,940 --> 00:24:05,470
Whereas in this case, Bob has
to wait until height 500,000,

485
00:24:05,470 --> 00:24:07,990
regardless of when he
broadcasts this transaction.

486
00:24:07,990 --> 00:24:10,540
So it may be that he can
broadcast this transaction

487
00:24:10,540 --> 00:24:13,390
and immediately spend
by signing here,

488
00:24:13,390 --> 00:24:15,580
because that time has passed.

489
00:24:15,580 --> 00:24:17,628
So it's seems like
a small distinction,

490
00:24:17,628 --> 00:24:19,420
but it's actually pretty
important for this

491
00:24:19,420 --> 00:24:23,130
to be just absolute time.

492
00:24:23,130 --> 00:24:24,910
So that's how an HTLC works.

493
00:24:24,910 --> 00:24:28,810
This output's
Alice's, no question.

494
00:24:28,810 --> 00:24:30,640
This output should be Bob's.

495
00:24:30,640 --> 00:24:33,850
And by should, I
mean something's

496
00:24:33,850 --> 00:24:38,920
gone pretty seriously wrong
if Alice takes this money.

497
00:24:38,920 --> 00:24:40,250
This only is due to fraud.

498
00:24:40,250 --> 00:24:42,250
And fraud is not like in
a legal, defined sense.

499
00:24:42,250 --> 00:24:45,370
But we sort of can
think of, basically,

500
00:24:45,370 --> 00:24:47,830
this is always going to be
Alice's, this is approximately

501
00:24:47,830 --> 00:24:49,360
always going to be Bob's.

502
00:24:49,360 --> 00:24:51,730
This one, we're really not sure.

503
00:24:51,730 --> 00:24:54,460
This can fail, and it's
not due to any malice.

504
00:24:54,460 --> 00:24:58,840
This can-- it should be Alice's.

505
00:24:58,840 --> 00:25:00,790
You're trying to pay Alice here.

506
00:25:00,790 --> 00:25:03,760
But it may well be the case
that Bob takes it back.

507
00:25:03,760 --> 00:25:05,410
And that's not due
to fraud, that's

508
00:25:05,410 --> 00:25:09,040
just due to computers crashing,
or networks not working right,

509
00:25:09,040 --> 00:25:10,540
or something like that.

510
00:25:10,540 --> 00:25:13,300
This can sort of
innocently be broadcast

511
00:25:13,300 --> 00:25:17,560
and go back to Bob,
whereas this can't, really.

512
00:25:17,560 --> 00:25:21,430
Any questions about
the HTLC basic idea?

513
00:25:21,430 --> 00:25:25,150
So Alice needs to
know this secret,

514
00:25:25,150 --> 00:25:28,020
or Bob has to wait
until a certain time.

515
00:25:28,020 --> 00:25:32,530
OK, so the cross-chain
swaps is basically

516
00:25:32,530 --> 00:25:34,810
the same as a routing
payment in Lightning.

517
00:25:34,810 --> 00:25:37,810
Before, we said, OK, Alice
has a channel with Bob,

518
00:25:37,810 --> 00:25:40,270
Bob has a channel
with Carol, and now

519
00:25:40,270 --> 00:25:44,710
Alice wants to pay Carol
without opening a new channel.

520
00:25:44,710 --> 00:25:46,480
In the case of
lightning, where it's

521
00:25:46,480 --> 00:25:48,280
all on the same
blockchain, Alice

522
00:25:48,280 --> 00:25:50,290
could open a payment
channel to Carol

523
00:25:50,290 --> 00:25:52,690
and spend directly that way.

524
00:25:52,690 --> 00:25:55,480
In the case where these two
are different blockchains,

525
00:25:55,480 --> 00:25:57,100
you can't actually do that.

526
00:25:57,100 --> 00:25:58,730
You can't say,
oh, I'm going to--

527
00:25:58,730 --> 00:26:00,850
there's no defined
channel that will

528
00:26:00,850 --> 00:26:03,840
link two different blockchains.

529
00:26:03,840 --> 00:26:05,310
The other aspect
is, although this

530
00:26:05,310 --> 00:26:07,290
can work with three
parties, in the case

531
00:26:07,290 --> 00:26:10,500
of swaps, you're
generally not saying,

532
00:26:10,500 --> 00:26:16,120
hey, Bob, I will pay you five
Dogecoins if you pay Carol 100

533
00:26:16,120 --> 00:26:17,070
Vertcoins.

534
00:26:17,070 --> 00:26:20,190
You're usually saying, if
you pay me 100 Vertcoins.

535
00:26:20,190 --> 00:26:24,270
So usually it's
Alice sending to Bob,

536
00:26:24,270 --> 00:26:26,610
who's sending back to Alice.

537
00:26:26,610 --> 00:26:29,300
It still works if this is
the third party, Carol.

538
00:26:29,300 --> 00:26:31,800
But it sort of doesn't make as
much sense, because generally

539
00:26:31,800 --> 00:26:34,258
you're saying, hey, I'll give
you this if you give me that.

540
00:26:36,020 --> 00:26:38,960
So in this case, we have
two different blockchains.

541
00:26:38,960 --> 00:26:40,880
We've actually reduced
the number of parties,

542
00:26:40,880 --> 00:26:42,303
where it's just Alice and Bob.

543
00:26:42,303 --> 00:26:43,970
But we've got two
different blockchains.

544
00:26:43,970 --> 00:26:46,580
We've got Dogecoin,
which I think is yellow,

545
00:26:46,580 --> 00:26:48,555
and then Vertcoin is greenish.

546
00:26:48,555 --> 00:26:50,400
AUDIENCE: [INAUDIBLE]

547
00:26:50,400 --> 00:26:52,400
TADGE DRYJA: Oh, because
they don't have SegWit.

548
00:26:52,400 --> 00:26:55,597
Well, say Dogecoin
upgrades pretty soon.

549
00:26:55,597 --> 00:26:57,090
[CHUCKLING]

550
00:26:57,090 --> 00:26:59,360
So you could, but you'd
have to write a lot of code

551
00:26:59,360 --> 00:27:00,620
to deal with that.

552
00:27:00,620 --> 00:27:04,002
And to us, it's way
easier to just merge and--

553
00:27:04,002 --> 00:27:06,750
AUDIENCE: They don't have
CHECKSEQUENCEVERIFY on?

554
00:27:06,750 --> 00:27:08,930
There's probably ways
around it, but yeah--

555
00:27:08,930 --> 00:27:10,170
TADGE DRYJA: Just upgrade--

556
00:27:10,170 --> 00:27:11,910
who's in charge of Doge?

557
00:27:11,910 --> 00:27:12,770
I don't know.

558
00:27:12,770 --> 00:27:14,300
Tell them to upgrade.

559
00:27:14,300 --> 00:27:18,080
So a lot of these
altcoins, there's

560
00:27:18,080 --> 00:27:20,242
sort of archaeological
aspects to them,

561
00:27:20,242 --> 00:27:21,950
where you can see
where they branched off

562
00:27:21,950 --> 00:27:23,900
of the main Bitcoin codebase.

563
00:27:23,900 --> 00:27:25,970
Because a lot of times
they don't get updated

564
00:27:25,970 --> 00:27:28,000
because no one's
really working on them.

565
00:27:28,000 --> 00:27:30,500
Despite no one really working
on them or looking at them,

566
00:27:30,500 --> 00:27:32,750
they can still be worth
a billion dollars,

567
00:27:32,750 --> 00:27:34,430
as I think Doge was
a few months ago.

568
00:27:36,725 --> 00:27:38,600
So sometimes they catch
up, and they're like,

569
00:27:38,600 --> 00:27:40,850
oh, let's take all the code
from Bitcoin that they've

570
00:27:40,850 --> 00:27:43,340
developed from the last
few years and apply it.

571
00:27:43,340 --> 00:27:45,680
Sometimes the opposite
happens, where an altcoin will

572
00:27:45,680 --> 00:27:48,710
make something cool, and people
in Bitcoin will merge it in,

573
00:27:48,710 --> 00:27:51,820
but it's generally the
opposite direction.

574
00:27:51,820 --> 00:27:57,280
OK, so you've got these two
channels that have been set up.

575
00:27:57,280 --> 00:28:03,040
And Alice wants to sell her
Dogecoin and buy Vertcoin.

576
00:28:03,040 --> 00:28:08,797
So you have the same HTLC
construction, where Alice--

577
00:28:08,797 --> 00:28:10,630
what's interesting in
this case is that it's

578
00:28:10,630 --> 00:28:11,690
the same person on both sides.

579
00:28:11,690 --> 00:28:13,815
So there's actually some
optimizations you can use.

580
00:28:13,815 --> 00:28:16,120
But forget those for a second.

581
00:28:16,120 --> 00:28:18,490
Alice computes a
random number, R,

582
00:28:18,490 --> 00:28:21,168
hashes it to make
H. She sends it

583
00:28:21,168 --> 00:28:23,710
to herself, which doesn't really
make any sense in this case.

584
00:28:23,710 --> 00:28:26,430
So you can skip that step.

585
00:28:26,430 --> 00:28:31,220
Alice already knows H
and already knows R, so--

586
00:28:31,220 --> 00:28:35,010
but Alice doesn't have to
be Alice, it could be Carol.

587
00:28:35,010 --> 00:28:36,930
So there's optimizations
that you can do

588
00:28:36,930 --> 00:28:39,150
when they're the same person.

589
00:28:39,150 --> 00:28:41,690
OK, so she constructs
an HTLC to Bob.

590
00:28:41,690 --> 00:28:45,930
She says, OK, if Bob knows
R, he gets this money.

591
00:28:45,930 --> 00:28:49,290
Otherwise, Alice gets
it after 5 o'clock.

592
00:28:49,290 --> 00:28:54,900
Bob says, OK, I don't know R,
so I can't get these Dogecoins.

593
00:28:54,900 --> 00:29:01,440
Bob then forwards it to Alice,
saying, OK, if Alice knows R,

594
00:29:01,440 --> 00:29:06,060
she gets the coins, if Bob
waits till after 4 o'clock,

595
00:29:06,060 --> 00:29:09,100
he gets the coins.

596
00:29:09,100 --> 00:29:11,830
So it's sort of like why
make this construction?

597
00:29:11,830 --> 00:29:17,100
It actually still makes sense,
because even though Bob knows

598
00:29:17,100 --> 00:29:22,650
that Alice knows R, Alice
will have to reveal R in order

599
00:29:22,650 --> 00:29:27,985
to take the coins, right?

600
00:29:27,985 --> 00:29:29,610
So it's saying, OK,
you need to know R,

601
00:29:29,610 --> 00:29:32,280
and you need to not just know R,
but you have to show everyone.

602
00:29:32,280 --> 00:29:34,740
Because the actual
script says, OK, you

603
00:29:34,740 --> 00:29:38,940
need to know the pre-image
of this 20-byte hash.

604
00:29:38,940 --> 00:29:41,130
And when you actually
spend, you have

605
00:29:41,130 --> 00:29:43,320
to put that pre-image
in the blockchain.

606
00:29:43,320 --> 00:29:46,200
You have to put it in your
input for your transaction,

607
00:29:46,200 --> 00:29:47,620
and then Bob can see it.

608
00:29:47,620 --> 00:29:51,180
So the idea is, if Alice closes
this channel in Vertcoin,

609
00:29:51,180 --> 00:29:54,360
takes the coins by using
R, Bob will know R,

610
00:29:54,360 --> 00:29:56,160
and Bob will know it's
the same R that he

611
00:29:56,160 --> 00:30:01,200
can use to take the coins
on the Dogecoin network.

612
00:30:01,200 --> 00:30:04,450
So you add these two HTLCs.

613
00:30:04,450 --> 00:30:06,100
You then clear them out.

614
00:30:06,100 --> 00:30:10,170
So instead of revealing
R on the blockchain,

615
00:30:10,170 --> 00:30:13,810
Alice can just reveal
R directly to Bob,

616
00:30:13,810 --> 00:30:16,600
say, I'm clearing out
this HTLC because here's

617
00:30:16,600 --> 00:30:20,860
R. You know that I can do this,
so just give me the coins.

618
00:30:20,860 --> 00:30:23,800
You also know R, so you
can take the coins yourself

619
00:30:23,800 --> 00:30:26,052
if I don't cooperate
on that end.

620
00:30:26,052 --> 00:30:27,010
But hopefully she does.

621
00:30:27,010 --> 00:30:28,542
So then you can get
rid of the HTLC.

622
00:30:28,542 --> 00:30:30,000
Now it's back down
the two outputs.

623
00:30:34,480 --> 00:30:38,210
And then Bob says, OK,
I've lost the Vertcoin

624
00:30:38,210 --> 00:30:40,810
and I haven't really
gotten the Dogecoin yet,

625
00:30:40,810 --> 00:30:44,160
but I know I can close the
channel and take it if need be.

626
00:30:44,160 --> 00:30:45,640
And then Bob goes
to Alice, and she

627
00:30:45,640 --> 00:30:49,270
already knows R, but look, you
know that I know R, let's clear

628
00:30:49,270 --> 00:30:50,590
this.

629
00:30:50,590 --> 00:30:52,650
And then Alice can just
send the coins that way.

630
00:30:55,990 --> 00:30:58,730
OK, so any questions
about this setup?

631
00:30:58,730 --> 00:30:59,763
Yes.

632
00:30:59,763 --> 00:31:01,180
AUDIENCE: Because
there's latency,

633
00:31:01,180 --> 00:31:05,605
can Alice mess with Bob,
basically, take the Vertcoin

634
00:31:05,605 --> 00:31:08,120
before Bob has a
chance to get the Doge,

635
00:31:08,120 --> 00:31:10,160
and basically screw Bob?

636
00:31:10,160 --> 00:31:13,340
TADGE DRYJA: Yeah, well, that's
why you have different times

637
00:31:13,340 --> 00:31:14,870
here.

638
00:31:14,870 --> 00:31:20,310
So yes, that is possible, that
you could get to this step,

639
00:31:20,310 --> 00:31:22,720
and then Alice goes offline
and shuts the channels down,

640
00:31:22,720 --> 00:31:23,880
closes the channels.

641
00:31:23,880 --> 00:31:28,950
But the idea is that Bob
can grab these coins back

642
00:31:28,950 --> 00:31:33,000
after 4 PM, whereas Alice
has to wait until 5 PM

643
00:31:33,000 --> 00:31:34,050
to grab these coins back.

644
00:31:36,650 --> 00:31:43,640
So if Alice closes and tries to
wait till right before 4:00 PM

645
00:31:43,640 --> 00:31:48,020
and then immediately grab
these coins, Bob's actually OK.

646
00:31:48,020 --> 00:31:50,950
Because Bob says, OK, well,
you grabbed the Vertcoins,

647
00:31:50,950 --> 00:31:55,440
but I actually have another
hour until I have to--

648
00:31:55,440 --> 00:31:57,380
I have an hour to reveal
R where you're not

649
00:31:57,380 --> 00:31:59,900
able to get these coins back.

650
00:31:59,900 --> 00:32:02,420
So having this incrementing
time can help against that.

651
00:32:06,230 --> 00:32:08,810
An hour is probably not enough.

652
00:32:08,810 --> 00:32:10,760
The trade-off to
having these times

653
00:32:10,760 --> 00:32:13,910
is, if you have it
very far in the future,

654
00:32:13,910 --> 00:32:18,290
with very large gaps, those
HTLCs can get stuck there.

655
00:32:18,290 --> 00:32:20,930
And if Alice just
says, look, I'm

656
00:32:20,930 --> 00:32:24,980
leaving this third output
in the transaction,

657
00:32:24,980 --> 00:32:26,150
that can be annoying.

658
00:32:26,150 --> 00:32:29,150
Or if it gets stuck on chain,
it might take a long time

659
00:32:29,150 --> 00:32:30,630
to get it back.

660
00:32:30,630 --> 00:32:32,870
So you want long
enough times that you

661
00:32:32,870 --> 00:32:34,700
don't worry about
these timing attacks,

662
00:32:34,700 --> 00:32:37,133
where someone
immediately broadcasts,

663
00:32:37,133 --> 00:32:39,425
and now you only have an
hour, and maybe the blockchain

664
00:32:39,425 --> 00:32:42,260
is congested.

665
00:32:42,260 --> 00:32:45,450
Versus the annoyance
of, oh, it closed,

666
00:32:45,450 --> 00:32:47,990
and now I have to
wait until 5:00 PM.

667
00:32:47,990 --> 00:32:50,130
So those are the
trade-offs there.

668
00:32:50,130 --> 00:32:51,578
Any other questions?

669
00:32:59,050 --> 00:33:03,740
OK, so cross-chain swaps--

670
00:33:03,740 --> 00:33:06,770
H can be revealed-- sorry, R--

671
00:33:06,770 --> 00:33:08,570
well, H just goes
into either chain,

672
00:33:08,570 --> 00:33:10,550
R is then revealed
on either chain,

673
00:33:10,550 --> 00:33:16,520
so that both parties need
to watch both blockchains.

674
00:33:16,520 --> 00:33:19,850
This sort of makes sense,
in that the channels are

675
00:33:19,850 --> 00:33:21,800
on two different
blockchains, and both parties

676
00:33:21,800 --> 00:33:25,220
have a channel on each.

677
00:33:25,220 --> 00:33:27,270
So the receiver doesn't
need to be the initiator.

678
00:33:27,270 --> 00:33:29,040
So it doesn't have to
be Alice on both sides,

679
00:33:29,040 --> 00:33:30,957
but in most cases I think
it probably will be.

680
00:33:33,800 --> 00:33:35,720
Alice has a Vertcoin
channel, Alice also

681
00:33:35,720 --> 00:33:38,450
has a Dogecoin
channel, as does Bob.

682
00:33:38,450 --> 00:33:40,940
So they need to be
operating on both networks.

683
00:33:40,940 --> 00:33:45,830
There are possibilities where
if you had, say, this was Carol,

684
00:33:45,830 --> 00:33:50,840
and she sent to Dave
using Litecoin--

685
00:33:50,840 --> 00:33:55,370
so if you have Alice, Bob,
Carol, Dave, Doge, Vertcoin,

686
00:33:55,370 --> 00:33:56,930
Litecoin--

687
00:33:56,930 --> 00:34:01,640
Alice would not have to know
about anything but Dogecoin.

688
00:34:01,640 --> 00:34:05,510
So you actually only have
to worry about the networks

689
00:34:05,510 --> 00:34:09,260
that you have channels in,
even though there are secrets

690
00:34:09,260 --> 00:34:11,639
that could appear in other--

691
00:34:11,639 --> 00:34:14,880
well, no, sorry,
that's not true.

692
00:34:14,880 --> 00:34:18,710
So if this is Carol, Alice
does have to look at Vertcoin,

693
00:34:18,710 --> 00:34:23,210
because the Vertcoin
network could show things.

694
00:34:23,210 --> 00:34:26,360
So you have to look at
one additional chain.

695
00:34:26,360 --> 00:34:30,460
So that's one of the issues
with cross-chain swaps, where

696
00:34:30,460 --> 00:34:34,480
you may be routing
through a network

697
00:34:34,480 --> 00:34:36,730
that you're not aware
of, essentially.

698
00:34:36,730 --> 00:34:39,580
I don't think that's
likely in practice.

699
00:34:39,580 --> 00:34:41,770
So like it could
be, I'll send you

700
00:34:41,770 --> 00:34:45,850
five Dogecoins if you
send her 20 Litecoins,

701
00:34:45,850 --> 00:34:49,190
and then you send back
Dogecoins to this other place,

702
00:34:49,190 --> 00:34:50,080
but it's possible.

703
00:34:50,080 --> 00:34:50,679
Yes.

704
00:34:50,679 --> 00:34:52,096
AUDIENCE: I just
want to make sure

705
00:34:52,096 --> 00:34:54,159
that I'm understanding this.

706
00:34:54,159 --> 00:34:57,430
So when they're both Alice,
essentially that scenario

707
00:34:57,430 --> 00:35:01,390
is Alice is exchanging
Dogecoin for Vertcoin.

708
00:35:01,390 --> 00:35:02,110
TADGE DRYJA: Yes.

709
00:35:02,110 --> 00:35:03,910
AUDIENCE: And then
if on the right

710
00:35:03,910 --> 00:35:10,930
is Carol, that's saying Alice is
going to pay Carol in Dogecoin,

711
00:35:10,930 --> 00:35:13,830
even though she's
receiving Vertcoin.

712
00:35:13,830 --> 00:35:14,650
TADGE DRYJA: Right.

713
00:35:14,650 --> 00:35:18,370
Carol receives Vertcoin,
Alice loses Dogecoin.

714
00:35:18,370 --> 00:35:20,260
So it's an exchange [INAUDIBLE].

715
00:35:20,260 --> 00:35:25,235
AUDIENCE: So it's like you're
paying [INAUDIBLE] never see

716
00:35:25,235 --> 00:35:26,290
[INAUDIBLE]

717
00:35:26,290 --> 00:35:27,040
TADGE DRYJA: Yeah.

718
00:35:27,040 --> 00:35:28,623
So like you go to
some other country--

719
00:35:28,623 --> 00:35:31,570
you go to England, you
pay with your credit card,

720
00:35:31,570 --> 00:35:34,120
you lose dollars
but they get pounds.

721
00:35:34,120 --> 00:35:38,130
And there's somehow-- there's
an exchange rate in the middle.

722
00:35:38,130 --> 00:35:40,630
And so from Bob's perspective,
it works the same either way.

723
00:35:40,630 --> 00:35:43,340
He's getting more Dogecoins
and losing Vertcoins.

724
00:35:43,340 --> 00:35:45,682
AUDIENCE: So Bob needs
to have a lot of--

725
00:35:45,682 --> 00:35:49,630
well, in this case, he only
really needs Vertcoins.

726
00:35:49,630 --> 00:35:50,440
TADGE DRYJA: Right.

727
00:35:50,440 --> 00:35:55,030
So it's possible that you set
up this by initially funding it.

728
00:35:55,030 --> 00:35:57,250
So Alice says, I have
a ton of Dogecoin.

729
00:35:57,250 --> 00:36:00,040
Alice creates this channel,
and she has like 100 dogecoins,

730
00:36:00,040 --> 00:36:01,530
and Bob has zero.

731
00:36:01,530 --> 00:36:03,030
And same with Vertcoin--

732
00:36:03,030 --> 00:36:04,780
Bob could have a lot
of them, and say, OK,

733
00:36:04,780 --> 00:36:07,620
I have 20 vertcoins
and Alice has zero,

734
00:36:07,620 --> 00:36:11,530
and then we can make those
payments in that direction.

735
00:36:11,530 --> 00:36:12,990
You can pay them--

736
00:36:12,990 --> 00:36:16,720
so actually, in all the
software now, I think,

737
00:36:16,720 --> 00:36:20,020
there's only
single-funded channels.

738
00:36:20,020 --> 00:36:22,150
Because having both parties
funded at the same time

739
00:36:22,150 --> 00:36:24,280
is kind of--

740
00:36:24,280 --> 00:36:27,250
software-wise, a little harder,
and it's also, interface-wise,

741
00:36:27,250 --> 00:36:28,840
going to be complicated.

742
00:36:28,840 --> 00:36:34,720
Because how do you know when
to match someone's funding?

743
00:36:34,720 --> 00:36:36,670
So usually what
you do is you say,

744
00:36:36,670 --> 00:36:39,040
I'm Alice, hey Bob,
what's your public key?

745
00:36:39,040 --> 00:36:40,450
Give me a new public key.

746
00:36:40,450 --> 00:36:42,190
OK, I'm going to
construct this channel.

747
00:36:42,190 --> 00:36:43,210
Here, sign this.

748
00:36:43,210 --> 00:36:44,770
And then Bob's like, OK.

749
00:36:44,770 --> 00:36:48,700
And Bob has no money at stake
when this process happens.

750
00:36:48,700 --> 00:36:51,005
And then Bob also creates a
channel with Alice, saying,

751
00:36:51,005 --> 00:36:53,380
OK, I'm going to put a bunch
of Vertcoin in this channel.

752
00:36:53,380 --> 00:36:56,172
And they usually start with
all the money on one side

753
00:36:56,172 --> 00:36:57,130
so they can then trade.

754
00:37:00,040 --> 00:37:02,170
Other questions?

755
00:37:02,170 --> 00:37:06,590
So they have to look at
these different channels

756
00:37:06,590 --> 00:37:09,710
on different blockchains in
order to make sure this works.

757
00:37:09,710 --> 00:37:12,210
There's still a lot of
open questions here.

758
00:37:12,210 --> 00:37:14,090
How do you actually trade?

759
00:37:14,090 --> 00:37:15,860
This is really good
for trade execution,

760
00:37:15,860 --> 00:37:17,550
but what about discovery?

761
00:37:17,550 --> 00:37:20,610
So the current exchanges,
they're not just

762
00:37:20,610 --> 00:37:23,930
"put all your money in here
and then ask for it back,"

763
00:37:23,930 --> 00:37:26,660
there's that middle step where
you find all the other parties.

764
00:37:29,400 --> 00:37:34,640
So post the orders on the
blockchain, and maybe?

765
00:37:34,640 --> 00:37:37,100
There's problems-- I mean,
it's not too crazy of an idea,

766
00:37:37,100 --> 00:37:38,960
but there's some
problems with it.

767
00:37:38,960 --> 00:37:41,657
If you just say, hey, I
want to sell dogecoins

768
00:37:41,657 --> 00:37:43,490
and I want to buy
vertcoins, and you sort of

769
00:37:43,490 --> 00:37:46,160
put that in an OP_RETURN
on the blockchain, well,

770
00:37:46,160 --> 00:37:47,330
it's non-binding.

771
00:37:47,330 --> 00:37:49,340
You don't have to
actually do anything.

772
00:37:49,340 --> 00:37:52,130
There can be frontrunning,
where the orders

773
00:37:52,130 --> 00:37:56,360
can go in the wrong
sequence or in time.

774
00:37:56,360 --> 00:38:01,640
And it's not scalable, because
if everyone's posting orders

775
00:38:01,640 --> 00:38:04,430
on the blockchain, that
can take up a lot of space,

776
00:38:04,430 --> 00:38:06,200
probably more so than
actual transactions.

777
00:38:06,200 --> 00:38:07,940
I don't know what--

778
00:38:07,940 --> 00:38:10,400
I mean, I'm sure-- maybe.

779
00:38:10,400 --> 00:38:13,070
Total number of orders
placed on a order

780
00:38:13,070 --> 00:38:16,640
book versus total number
of actual order executions,

781
00:38:16,640 --> 00:38:19,160
usually there's a
lot more orders that

782
00:38:19,160 --> 00:38:21,130
then end up getting canceled.

783
00:38:21,130 --> 00:38:22,880
Because in most exchanges
that I've seen--

784
00:38:22,880 --> 00:38:26,288
and I believe this is the
case in regular New York Stock

785
00:38:26,288 --> 00:38:27,830
Exchange kind of
things, you can say,

786
00:38:27,830 --> 00:38:29,990
hey, I want to sell
this at this price,

787
00:38:29,990 --> 00:38:32,692
and then a few minutes later you
say, yeah, I changed my mind.

788
00:38:32,692 --> 00:38:34,400
I don't to sell it at
that price anymore.

789
00:38:34,400 --> 00:38:36,800
The price has moved, and
I've changed my mind.

790
00:38:36,800 --> 00:38:38,050
And a lot of times--

791
00:38:38,050 --> 00:38:38,550
yeah.

792
00:38:38,550 --> 00:38:40,092
AUDIENCE: The New
York Stock Exchange

793
00:38:40,092 --> 00:38:43,580
runs about 100 messages
for every executed trade.

794
00:38:43,580 --> 00:38:47,720
TADGE DRYJA: OK, so about 1% of
the actual trades get executed.

795
00:38:47,720 --> 00:38:50,720
Yeah, that sounds
probably about the same

796
00:38:50,720 --> 00:38:53,125
as in a lot of
Bitcoin exchanges.

797
00:38:53,125 --> 00:38:54,500
Usually in the
Bitcoin exchanges,

798
00:38:54,500 --> 00:39:00,530
they don't charge you to post
an order and then take it back.

799
00:39:00,530 --> 00:39:01,208
That's free.

800
00:39:01,208 --> 00:39:02,750
Whereas the trade
actually executing,

801
00:39:02,750 --> 00:39:05,600
usually they have
some kind of fee.

802
00:39:05,600 --> 00:39:09,100
So posting the orders
themselves on the blockchain

803
00:39:09,100 --> 00:39:11,443
seems like a cool
idea, but you've

804
00:39:11,443 --> 00:39:12,860
got, now, this
scalability problem

805
00:39:12,860 --> 00:39:13,943
of all these transactions.

806
00:39:13,943 --> 00:39:16,720
Now it's probably
100 times worse.

807
00:39:16,720 --> 00:39:18,800
And frontrunning
could also be tricky.

808
00:39:18,800 --> 00:39:23,150
Because the blockchain does
provide sequence and timing,

809
00:39:23,150 --> 00:39:24,900
but it's up to the miners.

810
00:39:24,900 --> 00:39:27,380
So if you have a
10-minute window,

811
00:39:27,380 --> 00:39:29,090
during that 10-minute
window, the miners

812
00:39:29,090 --> 00:39:32,600
can basically shuffle things
around however they want.

813
00:39:32,600 --> 00:39:34,100
And so if the miner
is also trading,

814
00:39:34,100 --> 00:39:36,420
they can see, oh, I see
all these different orders,

815
00:39:36,420 --> 00:39:41,270
I will match these orders, and
let those happen afterwards.

816
00:39:41,270 --> 00:39:42,950
So this is an issue.

817
00:39:42,950 --> 00:39:45,800
So there's a bunch of different
models people are looking at.

818
00:39:45,800 --> 00:39:50,413
And to be clear here, this is
not something that really--

819
00:39:50,413 --> 00:39:52,830
I don't want to say it doesn't
exist yet, it sort of does.

820
00:39:52,830 --> 00:39:57,210
There are these decentralized
exchanges popping up, mostly

821
00:39:57,210 --> 00:39:59,430
on the Ethereum
network right now.

822
00:39:59,430 --> 00:40:01,560
Because then it's not
actually cross-chain.

823
00:40:01,560 --> 00:40:03,900
You can have cross-asset,
because there's

824
00:40:03,900 --> 00:40:06,990
all these ERC-20 tokens.

825
00:40:06,990 --> 00:40:09,240
But the cross-chain swaps
themselves are a bit more

826
00:40:09,240 --> 00:40:10,230
complicated to program.

827
00:40:10,230 --> 00:40:16,210
So I don't know of any
live, not-Mainnet operation

828
00:40:16,210 --> 00:40:17,300
like this.

829
00:40:17,300 --> 00:40:19,690
So one model would be you
have a central order book

830
00:40:19,690 --> 00:40:21,500
and a central counterparty.

831
00:40:21,500 --> 00:40:24,790
So the exchange says, OK,
we're still the exchange,

832
00:40:24,790 --> 00:40:28,060
we still have a website,
we still have order--

833
00:40:28,060 --> 00:40:31,440
buys, and sells,
and stuff like that.

834
00:40:31,440 --> 00:40:33,110
And not only that,
but the exchange

835
00:40:33,110 --> 00:40:35,060
is one side of every trade.

836
00:40:35,060 --> 00:40:37,760
So they say, OK, open
a channel with us,

837
00:40:37,760 --> 00:40:40,038
put all your vertcoins in,
put all your dogecoins in.

838
00:40:40,038 --> 00:40:42,080
And then we'll open a
different channel with you,

839
00:40:42,080 --> 00:40:43,940
and we'll put litecoins in it.

840
00:40:43,940 --> 00:40:46,390
And you trade with us.

841
00:40:46,390 --> 00:40:48,140
But then what they can
do is they can say,

842
00:40:48,140 --> 00:40:49,765
well, we're not
actually going to trade

843
00:40:49,765 --> 00:40:52,760
unless there's someone
else performing

844
00:40:52,760 --> 00:40:55,003
a similar, opposite trade.

845
00:40:55,003 --> 00:40:56,420
And then they can
keep the spread.

846
00:40:56,420 --> 00:40:59,720
So they say, OK, we're
selling Vertcoin at this rate

847
00:40:59,720 --> 00:41:03,540
and buying it at this other,
slightly different rate.

848
00:41:03,540 --> 00:41:06,680
So that seems the most feasible.

849
00:41:06,680 --> 00:41:09,830
I would venture that that's
going to happen first,

850
00:41:09,830 --> 00:41:13,340
because it's not too crazy.

851
00:41:13,340 --> 00:41:14,810
But it has similar
centralization

852
00:41:14,810 --> 00:41:16,340
to the current model.

853
00:41:16,340 --> 00:41:18,500
But there is less
counterparty risk.

854
00:41:18,500 --> 00:41:21,950
So if you are worried
about an exchange shutting

855
00:41:21,950 --> 00:41:25,070
down and running off with all
your Dogecoin, this can help.

856
00:41:25,070 --> 00:41:27,320
Say, OK, well, I have a
channel with my Dogecoin in it

857
00:41:27,320 --> 00:41:29,172
and a channel with
my Vertcoin in it,

858
00:41:29,172 --> 00:41:31,130
and I can sell some
Dogecoin, get some Vertcoin

859
00:41:31,130 --> 00:41:34,790
from the exchange, and I
still have a nice order book.

860
00:41:34,790 --> 00:41:37,660
It doesn't solve any kind
of frontrunning problem.

861
00:41:37,660 --> 00:41:40,360
The exchange can still
order things how they want.

862
00:41:40,360 --> 00:41:42,500
And the exchange
can still shut down.

863
00:41:42,500 --> 00:41:45,320
But it's much more
difficult for the exchange

864
00:41:45,320 --> 00:41:50,640
to somehow steal your coins,
which is a problem now.

865
00:41:50,640 --> 00:41:54,260
Another model-- you say, well,
we have a central order book,

866
00:41:54,260 --> 00:41:58,700
so the exchange still
exists and aggregates

867
00:41:58,700 --> 00:42:01,730
all the orders of everyone
who wants to buy and sell.

868
00:42:01,730 --> 00:42:03,910
But there's multiple
counterparties

869
00:42:03,910 --> 00:42:06,070
that you interact with directly.

870
00:42:06,070 --> 00:42:08,830
So the exchange says,
OK, I'm E, and I

871
00:42:08,830 --> 00:42:11,080
will tell Alice about Bob.

872
00:42:11,080 --> 00:42:14,080
Alice says, hey, I
want to sell Dogecoin

873
00:42:14,080 --> 00:42:17,310
and buy Vertcoin at this rate.

874
00:42:17,310 --> 00:42:20,050
And then the exchange tells
Alice and Bob, OK, you guys

875
00:42:20,050 --> 00:42:20,800
matched.

876
00:42:20,800 --> 00:42:24,430
Bob, you want to sell Vertcoin,
Alice, you want to buy it.

877
00:42:24,430 --> 00:42:28,660
Here, connect to each other
and perform this trade.

878
00:42:28,660 --> 00:42:31,990
This is cooler, but
there's questions,

879
00:42:31,990 --> 00:42:34,840
in that if you're connecting
to many counterparties,

880
00:42:34,840 --> 00:42:36,100
it's costly.

881
00:42:36,100 --> 00:42:39,220
You have to open a new
channel, and that is on chain.

882
00:42:39,220 --> 00:42:42,010
Also, how do you
enforce trade execution?

883
00:42:42,010 --> 00:42:46,790
If it's a trade on a current
exchange, and you say,

884
00:42:46,790 --> 00:42:49,890
OK, I want to buy bitcoins,
And you click, OK, it just

885
00:42:49,890 --> 00:42:50,530
happened.

886
00:42:50,530 --> 00:42:52,000
They are aren't
even your bitcoins.

887
00:42:52,000 --> 00:42:53,720
You don't really
have control of them.

888
00:42:53,720 --> 00:42:55,428
So when you say you
want to do something,

889
00:42:55,428 --> 00:42:57,340
they actually execute it.

890
00:42:57,340 --> 00:43:00,700
In this case, if they don't
have a channel with you,

891
00:43:00,700 --> 00:43:03,850
they just are observing
the trade occur.

892
00:43:03,850 --> 00:43:08,740
So they're saying, OK,
Alice and Bob, do this.

893
00:43:08,740 --> 00:43:11,652
It might not even be
possible to enforce.

894
00:43:11,652 --> 00:43:13,360
You'd have to have
some kind of penalties

895
00:43:13,360 --> 00:43:16,330
if Bob says hey, Alice,
said she was going to sell,

896
00:43:16,330 --> 00:43:19,860
but then didn't, or Bob
complains, things like that.

897
00:43:22,470 --> 00:43:25,480
So there's a lot of ideas here.

898
00:43:25,480 --> 00:43:29,200
Another is, OK, if
you're building channels,

899
00:43:29,200 --> 00:43:31,660
each channel that you built
has these unchained costs

900
00:43:31,660 --> 00:43:33,680
and takes quite a bit of time.

901
00:43:33,680 --> 00:43:36,700
So maybe you could have
a multi-hop network

902
00:43:36,700 --> 00:43:38,150
from different coins.

903
00:43:38,150 --> 00:43:41,260
So instead of just
Alice, Bob, Alice,

904
00:43:41,260 --> 00:43:43,180
you've got Dave and Carol.

905
00:43:43,180 --> 00:43:47,470
And as long as I'm connected
to someone in this network,

906
00:43:47,470 --> 00:43:50,710
I can route payments to them
and they can route payments

907
00:43:50,710 --> 00:43:52,390
to me via different channels.

908
00:43:52,390 --> 00:43:56,377
So I'm connected to this
multicoin network kind of mesh.

909
00:43:56,377 --> 00:43:57,460
That would be really cool.

910
00:44:00,250 --> 00:44:02,260
It's not implemented.

911
00:44:02,260 --> 00:44:04,190
It's not even really
researched that well yet.

912
00:44:04,190 --> 00:44:07,070
So these are sort of ideas.

913
00:44:07,070 --> 00:44:08,320
But that would be really cool.

914
00:44:08,320 --> 00:44:10,028
Then you wouldn't need
as much liquidity.

915
00:44:10,028 --> 00:44:13,762
So one of the issues with the
central counterparty model

916
00:44:13,762 --> 00:44:15,970
is the exchange still needs
to have a bunch of money.

917
00:44:15,970 --> 00:44:18,460
They still need to have a bunch
of dogecoins and vertcoins

918
00:44:18,460 --> 00:44:21,670
in order to be a
counterparty to every trade.

919
00:44:21,670 --> 00:44:24,460
And then the question is, well,
where did those come from?

920
00:44:24,460 --> 00:44:29,140
And if you say, oh, well, it
comes from customers, well,

921
00:44:29,140 --> 00:44:32,050
now that's back into
the custodial model,

922
00:44:32,050 --> 00:44:37,120
where they still have coins
that aren't really theirs.

923
00:44:37,120 --> 00:44:39,460
You could say, well, they--

924
00:44:39,460 --> 00:44:41,470
and what I'm guessing
is going to happen

925
00:44:41,470 --> 00:44:44,260
is they're going to say,
well, we charge a spread,

926
00:44:44,260 --> 00:44:46,850
and we'll accept investors.

927
00:44:46,850 --> 00:44:50,470
And so if you want to
invest in this exchange,

928
00:44:50,470 --> 00:44:53,050
give us a bunch of Dogecoin,
give us a bunch of Vertcoin.

929
00:44:53,050 --> 00:44:58,223
We will then use it to trade
with different parties,

930
00:44:58,223 --> 00:44:59,890
and then we'll keep
some kind of spread,

931
00:44:59,890 --> 00:45:03,640
and then, hey, you got a return
on your invested Dogecoin.

932
00:45:03,640 --> 00:45:05,140
You get more
Dogecoin at the end,

933
00:45:05,140 --> 00:45:07,763
and then you can withdraw it.

934
00:45:07,763 --> 00:45:10,180
I think this is still better
than the current model, where

935
00:45:10,180 --> 00:45:12,280
you leave a whole bunch
of coins on the exchange,

936
00:45:12,280 --> 00:45:14,740
and you get nothing.

937
00:45:14,740 --> 00:45:15,670
Now you can choose--

938
00:45:15,670 --> 00:45:18,520
OK, do I want to
give them my coins

939
00:45:18,520 --> 00:45:20,770
and take that counterparty
risk, but I get some return

940
00:45:20,770 --> 00:45:23,260
in exchange for that
risk, or do I just

941
00:45:23,260 --> 00:45:25,330
want to trade without
counterparty risk.

942
00:45:25,330 --> 00:45:28,390
So, another problem
with that model.

943
00:45:28,390 --> 00:45:30,940
But that's probably
what will happen.

944
00:45:30,940 --> 00:45:33,940
This doesn't have that
issue, in that there

945
00:45:33,940 --> 00:45:36,730
is no central counterparty who
needs to have a bunch of coins.

946
00:45:36,730 --> 00:45:39,002
I'm trading directly with
the people who own the coins

947
00:45:39,002 --> 00:45:39,710
and want to sell.

948
00:45:39,710 --> 00:45:40,213
Yeah.

949
00:45:40,213 --> 00:45:41,755
AUDIENCE: My question
is, even if you

950
00:45:41,755 --> 00:45:44,800
have this central role and
multiple counterparties,

951
00:45:44,800 --> 00:45:48,910
wouldn't there still
be these trader nodes

952
00:45:48,910 --> 00:45:52,672
that are going to go out
there and essentially

953
00:45:52,672 --> 00:45:54,019
be kind of the same thing?

954
00:45:54,019 --> 00:45:55,686
They're going to be
well-funded, they're

955
00:45:55,686 --> 00:45:58,990
going take fees by doing all
these different transactions,

956
00:45:58,990 --> 00:46:01,870
and they're going to
get bigger and bigger.

957
00:46:01,870 --> 00:46:04,100
TADGE DRYJA: Yes, I guess
the only distinction is--

958
00:46:04,100 --> 00:46:04,835
so yes,

959
00:46:04,835 --> 00:46:06,460
AUDIENCE: It just
allows it to happen--

960
00:46:06,460 --> 00:46:09,670
TADGE DRYJA: Over the not
even long term-- medium term--

961
00:46:09,670 --> 00:46:13,330
these, as a user interface,
they'll look the same.

962
00:46:13,330 --> 00:46:15,160
Because whether
it's the exchange

963
00:46:15,160 --> 00:46:17,380
itself saying, OK,
I'm aggregating,

964
00:46:17,380 --> 00:46:19,600
everyone deposit, I've
got a ton of capital,

965
00:46:19,600 --> 00:46:22,058
I'm going to be a counterparty
to these trades and a market

966
00:46:22,058 --> 00:46:26,080
maker, versus, oh, there's
no defined market maker,

967
00:46:26,080 --> 00:46:27,970
but the people
with a lot of money

968
00:46:27,970 --> 00:46:31,510
or who are really trying to do
this end up in that position.

969
00:46:31,510 --> 00:46:34,750
I guess the only difference
is, in this case,

970
00:46:34,750 --> 00:46:37,690
the counterparty is also
running the order book.

971
00:46:37,690 --> 00:46:40,430
And in this case,
they may be different.

972
00:46:40,430 --> 00:46:42,940
There's an order book
server, and then there's

973
00:46:42,940 --> 00:46:45,130
this big counterparty who
has a ton of money who's

974
00:46:45,130 --> 00:46:46,870
doing all the trades.

975
00:46:46,870 --> 00:46:50,168
So does that make
much of a difference.

976
00:46:50,168 --> 00:46:50,710
I don't know.

977
00:46:50,710 --> 00:46:51,215
Yes.

978
00:46:51,215 --> 00:46:52,715
AUDIENCE: In the
history of markets,

979
00:46:52,715 --> 00:46:54,740
the second example is the
one that you see more.

980
00:46:54,740 --> 00:46:55,948
AUDIENCE: Right, yeah, right?

981
00:46:55,948 --> 00:46:59,920
New York Stock Exchange, London
Stock Exchange, and so on.

982
00:46:59,920 --> 00:47:03,930
The first model has
the centralized party

983
00:47:03,930 --> 00:47:07,544
collecting huge economic rents
because they're centralized,

984
00:47:07,544 --> 00:47:09,502
which is kind of interesting,
where Bitcoin was

985
00:47:09,502 --> 00:47:13,305
supposed to be decentralized.

986
00:47:13,305 --> 00:47:15,210
TADGE DRYJA: Yeah,
so this probably

987
00:47:15,210 --> 00:47:19,290
ends up with a small
number of pretty big nodes,

988
00:47:19,290 --> 00:47:20,940
mostly because of
the efficiency.

989
00:47:20,940 --> 00:47:23,760
If you're connecting to 100
different counterparties,

990
00:47:23,760 --> 00:47:26,280
and then you never actually
trade with any of them,

991
00:47:26,280 --> 00:47:28,560
it's very costly to
build those channels,

992
00:47:28,560 --> 00:47:31,440
and which probably has
analogies to, in real life,

993
00:47:31,440 --> 00:47:34,015
it's costly to maintain
these relationships

994
00:47:34,015 --> 00:47:35,890
with all these different
companies and stuff.

995
00:47:35,890 --> 00:47:38,040
It's much more efficient
if we just all meet

996
00:47:38,040 --> 00:47:41,660
under this buttonwood tree.

997
00:47:41,660 --> 00:47:44,680
It's a different issue in that,
enforcing trade execution,

998
00:47:44,680 --> 00:47:47,390
you might not have legal--

999
00:47:47,390 --> 00:47:49,790
you might not know who any
of these people are legally.

1000
00:47:49,790 --> 00:47:51,680
So you have some
kind of penalties

1001
00:47:51,680 --> 00:47:55,070
or some kind of proofs that the
trade occurred the correct way,

1002
00:47:55,070 --> 00:47:56,780
things like that.

1003
00:47:56,780 --> 00:47:57,280
Yes.

1004
00:47:57,280 --> 00:47:58,738
AUDIENCE: How about
the enforcing--

1005
00:47:58,738 --> 00:48:03,530
[INAUDIBLE] what we'd call
it, but the way the trades are

1006
00:48:03,530 --> 00:48:06,875
set up, do you need
to enforce them,

1007
00:48:06,875 --> 00:48:08,750
or before you enter into
them, do you already

1008
00:48:08,750 --> 00:48:10,830
know what [INAUDIBLE]

1009
00:48:10,830 --> 00:48:16,010
TADGE DRYJA: So the
example is, before you--

1010
00:48:16,010 --> 00:48:20,090
OK, so the example is,
Alice goes to a server.

1011
00:48:20,090 --> 00:48:23,660
So you have an exchange,
but this exchange

1012
00:48:23,660 --> 00:48:25,160
is only the order book.

1013
00:48:25,160 --> 00:48:28,010
So there's little buy
and sell kind of things.

1014
00:48:28,010 --> 00:48:34,950
And then Alice says,
OK, I want to buy VTC.

1015
00:48:34,950 --> 00:48:36,130
And then-- this is Alice--

1016
00:48:36,130 --> 00:48:40,720
Bob says, OK, I want
to buy Dogecoin.

1017
00:48:43,770 --> 00:48:46,080
Then the exchange says,
oh, you guys crossed.

1018
00:48:46,080 --> 00:48:48,120
You want to buy
Vertcoin at a rate

1019
00:48:48,120 --> 00:48:52,140
that he's willing to sell at,
or slightly higher, or whatever,

1020
00:48:52,140 --> 00:48:54,240
so trade.

1021
00:48:54,240 --> 00:48:57,520
So the exchange tells both
people, hey, you matched,

1022
00:48:57,520 --> 00:49:00,270
now you have to trade.

1023
00:49:00,270 --> 00:49:03,210
And then as soon as A sees, oh,
you matched, you have to trade,

1024
00:49:03,210 --> 00:49:08,420
Alice disappears, and
says, oh, I didn't mean to.

1025
00:49:08,420 --> 00:49:12,550
So the exchange only
can provide information.

1026
00:49:12,550 --> 00:49:14,470
They can't actually
force Alice and Bob

1027
00:49:14,470 --> 00:49:17,256
to do the trade is the problem.

1028
00:49:17,256 --> 00:49:17,923
AUDIENCE: Right.

1029
00:49:17,923 --> 00:49:20,492
I guess you can broadcast--

1030
00:49:20,492 --> 00:49:22,850
in broadcasting your
potential trade,

1031
00:49:22,850 --> 00:49:25,793
there's information for somebody
to come in at those-- so

1032
00:49:25,793 --> 00:49:30,720
if it's at a specific
price, and you're actually

1033
00:49:30,720 --> 00:49:34,280
publishing what you would need
to actually execute the trade.

1034
00:49:34,280 --> 00:49:35,700
TADGE DRYJA: Ah, so that--

1035
00:49:35,700 --> 00:49:40,140
yeah, at least in Bitcoin,
I don't know how to do that.

1036
00:49:40,140 --> 00:49:43,770
Because you need to know who
your counterparty is in order

1037
00:49:43,770 --> 00:49:47,700
to either use these channels,
or even if it were on chain,

1038
00:49:47,700 --> 00:49:49,650
you have to share these secret--

1039
00:49:49,650 --> 00:49:51,960
it's interactive with
your counterparty.

1040
00:49:51,960 --> 00:49:55,490
So at least in Bitcoin, I
don't know a way to say,

1041
00:49:55,490 --> 00:50:00,150
Alice is posting her buy
Vertcoin order in a way

1042
00:50:00,150 --> 00:50:01,980
that anyone can
then go and fill it

1043
00:50:01,980 --> 00:50:06,930
without additional
interactivity from Alice.

1044
00:50:06,930 --> 00:50:09,390
I think there's ways
to do that in Ethereum,

1045
00:50:09,390 --> 00:50:12,060
for Ethereum tokens, and
there are people who've

1046
00:50:12,060 --> 00:50:13,900
written software like that.

1047
00:50:13,900 --> 00:50:17,180
But in the Bitcoin model,
there might be a way to do it.

1048
00:50:17,180 --> 00:50:20,450
We haven't figured it out.

1049
00:50:20,450 --> 00:50:21,530
So it's sort of--

1050
00:50:21,530 --> 00:50:24,440
you put in your orders,
they return and say, OK,

1051
00:50:24,440 --> 00:50:25,783
trade, and now--

1052
00:50:25,783 --> 00:50:27,700
AUDIENCE: You have to
create the [INAUDIBLE]..

1053
00:50:27,700 --> 00:50:30,075
TADGE DRYJA: Yeah, now they
have to continue to interact.

1054
00:50:30,075 --> 00:50:32,440
So it's pretty straightforward
for Bob or Alice--

1055
00:50:32,440 --> 00:50:35,570
Alice could just unplug her
computer right at that point.

1056
00:50:35,570 --> 00:50:40,580
And that introduces timing
sort of issues where Alice just

1057
00:50:40,580 --> 00:50:43,160
puts in all these fake trades.

1058
00:50:43,160 --> 00:50:45,270
Maybe they're kind of out there.

1059
00:50:45,270 --> 00:50:47,270
But sometimes the market
moves during the time

1060
00:50:47,270 --> 00:50:52,650
between I put my trade in
and the execution comes back.

1061
00:50:52,650 --> 00:50:54,417
And so I unplug most of them.

1062
00:50:54,417 --> 00:50:56,750
I ignore most of them, but
the ones that are beneficial,

1063
00:50:56,750 --> 00:50:58,620
I actually go through with.

1064
00:50:58,620 --> 00:51:01,220
AUDIENCE: Which isn't too far
from the way the markets work.

1065
00:51:01,220 --> 00:51:02,220
TADGE DRYJA: Well, yeah.

1066
00:51:02,220 --> 00:51:03,640
[CHUCKLING]

1067
00:51:05,762 --> 00:51:07,220
AUDIENCE: The
difference is, you're

1068
00:51:07,220 --> 00:51:10,130
saying these are not live
hot bids and hot offers,

1069
00:51:10,130 --> 00:51:12,812
meaning executable.

1070
00:51:12,812 --> 00:51:16,730
They had another step
if they were executable.

1071
00:51:16,730 --> 00:51:19,680
So this is a new
form of spoofing.

1072
00:51:19,680 --> 00:51:22,820
This spoofing goes on
in the US swaps market

1073
00:51:22,820 --> 00:51:26,650
all the time, because
[INAUDIBLE] bids and offers.

1074
00:51:26,650 --> 00:51:29,040
But in the market where
there's executable bids

1075
00:51:29,040 --> 00:51:33,220
and offers, that's the
distinction-- this is not hot.

1076
00:51:33,220 --> 00:51:35,400
[INAUDIBLE]

1077
00:51:35,400 --> 00:51:36,290
TADGE DRYJA: Right.

1078
00:51:36,290 --> 00:51:38,120
I guess so "hot" in
this case would be--

1079
00:51:41,690 --> 00:51:45,530
if Alice's offer contains all
the information needed by Bob

1080
00:51:45,530 --> 00:51:47,242
to execute the
trade, then it would

1081
00:51:47,242 --> 00:51:48,950
be sort of hot in that
sense, in that Bob

1082
00:51:48,950 --> 00:51:53,060
doesn't have to interact with
Alice anymore to execute.

1083
00:51:53,060 --> 00:51:55,970
With these construction--
with the cross-chain swaps,

1084
00:51:55,970 --> 00:52:01,200
using these channels, you still
have to talk to each other.

1085
00:52:01,200 --> 00:52:03,590
Bob generates-- no, Alice
generates the R value,

1086
00:52:03,590 --> 00:52:05,150
shares the hash with Bob.

1087
00:52:05,150 --> 00:52:06,860
They're talking to each other.

1088
00:52:06,860 --> 00:52:08,030
So we don't know--

1089
00:52:08,030 --> 00:52:10,880
if someone figures out a cool
way to do it, then great,

1090
00:52:10,880 --> 00:52:13,690
that will solve this issue.

1091
00:52:13,690 --> 00:52:14,323
Yes.

1092
00:52:14,323 --> 00:52:19,360
AUDIENCE: Is 0x and Radar
Relay, are they hot [INAUDIBLE]

1093
00:52:19,360 --> 00:52:22,430
TADGE DRYJA: I believe 0x
is, from what I've read.

1094
00:52:22,430 --> 00:52:26,390
I don't know about how
[STAMMERING] whatever that is--

1095
00:52:26,390 --> 00:52:27,610
Radar Relay works.

1096
00:52:27,610 --> 00:52:32,210
But 0x, yeah,
basically, your order

1097
00:52:32,210 --> 00:52:37,480
is executable by any party
without further input from you.

1098
00:52:37,480 --> 00:52:38,980
But it also has scaling issues.

1099
00:52:38,980 --> 00:52:41,650
So that's a good segue way
to the next part, which

1100
00:52:41,650 --> 00:52:44,740
is having some kind of
distributed order book, where

1101
00:52:44,740 --> 00:52:46,930
there is no central
order book, there

1102
00:52:46,930 --> 00:52:49,240
is no central counterparty,
the whole thing

1103
00:52:49,240 --> 00:52:51,910
is a big mesh network
kind of thing.

1104
00:52:51,910 --> 00:52:53,710
That would be really cool.

1105
00:52:53,710 --> 00:52:57,555
That seems the furthest out, in
terms of, how do you do this.

1106
00:52:57,555 --> 00:52:58,930
I mean, people
are working on it,

1107
00:52:58,930 --> 00:53:02,290
but it seems hard to
make practical in that

1108
00:53:02,290 --> 00:53:03,850
how do you ensure
fairness, right?

1109
00:53:03,850 --> 00:53:05,465
Who's ordering these things?

1110
00:53:05,465 --> 00:53:07,090
And you could say,
well, the blockchain

1111
00:53:07,090 --> 00:53:08,320
is ordering these things.

1112
00:53:08,320 --> 00:53:11,410
But that ends up being
that the miners order it.

1113
00:53:11,410 --> 00:53:15,130
So if Alice is buy
Vertcoin, she's like, OK,

1114
00:53:15,130 --> 00:53:18,170
I'm buying Vertcoin
at a price of 5.

1115
00:53:18,170 --> 00:53:19,820
And then he says,
OK, I'll buy Doge

1116
00:53:19,820 --> 00:53:23,810
at a price of whatever--
basically, you cross,

1117
00:53:23,810 --> 00:53:28,010
and you have an order where
there's some kind of overlap.

1118
00:53:28,010 --> 00:53:31,310
The miner can say, OK, well,
I'll instead ignore this order,

1119
00:53:31,310 --> 00:53:35,810
execute my own, and then
execute with this guy

1120
00:53:35,810 --> 00:53:37,640
and take the spread.

1121
00:53:37,640 --> 00:53:40,250
Because the miner really gets
to sequence things however

1122
00:53:40,250 --> 00:53:41,240
they want.

1123
00:53:41,240 --> 00:53:43,880
The blockchain does
provide ordering,

1124
00:53:43,880 --> 00:53:45,080
but at the block level.

1125
00:53:45,080 --> 00:53:47,390
Within a block, it's
totally up to the miner.

1126
00:53:47,390 --> 00:53:50,800
So the miners could
swap things around.

1127
00:53:50,800 --> 00:53:53,390
But yeah, how do you ensure
fairness in terms of timing?

1128
00:53:53,390 --> 00:53:55,700
How do you enforce
trade execution?

1129
00:53:55,700 --> 00:53:58,340
And probably the biggest
for a distributed order book

1130
00:53:58,340 --> 00:54:01,220
is just the scalability
of the orders.

1131
00:54:01,220 --> 00:54:05,180
You probably don't want to put
all the orders on a blockchain,

1132
00:54:05,180 --> 00:54:09,320
because it just ends
up being a ton of data.

1133
00:54:09,320 --> 00:54:12,770
So you have to have some
kind of broadcast network

1134
00:54:12,770 --> 00:54:15,350
where you've got these
orders, they probably

1135
00:54:15,350 --> 00:54:19,280
should have some way to
expire, but expiry is also

1136
00:54:19,280 --> 00:54:24,830
an issue in that, how
do you ensure that--

1137
00:54:24,830 --> 00:54:26,390
hey, I'm canceling
this order, how

1138
00:54:26,390 --> 00:54:28,223
do you ensure that the
cancellation actually

1139
00:54:28,223 --> 00:54:31,480
propagates if someone
can say, OK, I've

1140
00:54:31,480 --> 00:54:33,520
got pretty good
control of the network,

1141
00:54:33,520 --> 00:54:36,580
and I can just block
these order cancellations,

1142
00:54:36,580 --> 00:54:39,040
and wait, and then execute.

1143
00:54:39,040 --> 00:54:40,510
So this is sort of--

1144
00:54:40,510 --> 00:54:45,080
there's papers, there's ideas,
but it's kind of out there.

1145
00:54:47,940 --> 00:54:51,480
OK, so that's basically--
yeah, that was it.

1146
00:54:51,480 --> 00:54:52,720
That's a little earlier.

1147
00:54:52,720 --> 00:54:56,820
But yeah, this was basically
the stuff for today.

1148
00:54:56,820 --> 00:54:58,740
The idea works, right,
the cross-chain swaps.

1149
00:54:58,740 --> 00:55:01,600
But there's still a lot
of issues, in terms of,

1150
00:55:01,600 --> 00:55:03,750
OK, how do you actually
get these to work?

1151
00:55:03,750 --> 00:55:06,600
How do you build a
scalable trading platform?

1152
00:55:06,600 --> 00:55:08,400
And there aren't really any yet.

1153
00:55:08,400 --> 00:55:12,420
There are some things on
Ethereum that work OK.

1154
00:55:12,420 --> 00:55:14,400
The fees end up
being kind of high.

1155
00:55:14,400 --> 00:55:16,590
And that's also
Ethereum, where it's not

1156
00:55:16,590 --> 00:55:18,332
between different blockchains.

1157
00:55:18,332 --> 00:55:20,040
It's all running on
the Ethereum network,

1158
00:55:20,040 --> 00:55:22,830
and the Ethereum network
allows you to specify,

1159
00:55:22,830 --> 00:55:25,860
well, this is actually something
else, this isn't ether.

1160
00:55:25,860 --> 00:55:28,010
You can do that
in Bitcoin, but--

1161
00:55:28,010 --> 00:55:29,790
so there are
protocols in Bitcoin,

1162
00:55:29,790 --> 00:55:33,510
like Omni, and
Mastercoin, and things,

1163
00:55:33,510 --> 00:55:36,150
where you can sort of
create different assets

1164
00:55:36,150 --> 00:55:38,400
by using OP_RETURN.

1165
00:55:38,400 --> 00:55:40,650
And basically all of those
have moved to Ethereum now,

1166
00:55:40,650 --> 00:55:44,153
because Ethereum is a much
nicer design for those things.

1167
00:55:44,153 --> 00:55:46,320
And most of the Bitcoin
developers are sort of like,

1168
00:55:46,320 --> 00:55:52,300
great, now all these non-Bitcoin
transaction data have left,

1169
00:55:52,300 --> 00:55:55,410
and Bitcoin is just focused
on moving bitcoin around.

1170
00:55:55,410 --> 00:55:57,210
Yeah, so the basic
idea works, there's

1171
00:55:57,210 --> 00:55:59,550
still a lot of unsolved
questions-- further research

1172
00:55:59,550 --> 00:56:02,512
required, which is great to
hear when you're a researcher.

1173
00:56:02,512 --> 00:56:03,750
[CHUCKLING]

1174
00:56:03,750 --> 00:56:05,640
And there's people
working on this here.

1175
00:56:05,640 --> 00:56:08,760
I'm working with an MEng
student on cross-chain swaps

1176
00:56:08,760 --> 00:56:09,420
this semester.

1177
00:56:09,420 --> 00:56:11,128
There's other people
working on all sorts

1178
00:56:11,128 --> 00:56:12,810
of decentralized
exchange things.

1179
00:56:12,810 --> 00:56:14,460
Neha is also very
interested in it.

1180
00:56:14,460 --> 00:56:19,500
So if you want to work
with Neha, that's a chance.

1181
00:56:19,500 --> 00:56:21,120
And yeah, I think
it'll be big, right?

1182
00:56:21,120 --> 00:56:23,520
Because if you look
at these exchanges,

1183
00:56:23,520 --> 00:56:25,980
there's a lot of profit.

1184
00:56:25,980 --> 00:56:29,750
So I don't know, a year or two
ago, you look at like Poloniex,

1185
00:56:29,750 --> 00:56:32,490
they were making like
$1 million a day.

1186
00:56:32,490 --> 00:56:34,050
There's so much volume.

1187
00:56:34,050 --> 00:56:37,210
And they have very
few employees.

1188
00:56:37,210 --> 00:56:39,870
So and they're like--

1189
00:56:39,870 --> 00:56:43,500
I think the market is getting
sort of more established now,

1190
00:56:43,500 --> 00:56:45,270
in terms of its going
to be larger players

1191
00:56:45,270 --> 00:56:46,320
and stuff like that.

1192
00:56:46,320 --> 00:56:49,140
But it was pretty much like
Wild Wild West a few years ago,

1193
00:56:49,140 --> 00:56:51,390
where you're just like, I'm
going to open an exchange,

1194
00:56:51,390 --> 00:56:54,870
and I don't even
need a bank account.

1195
00:56:54,870 --> 00:56:58,200
The big exchanges that have
bank accounts I feel like

1196
00:56:58,200 --> 00:56:59,820
are less profitable.

1197
00:56:59,820 --> 00:57:01,650
So Coinbase makes
a lot of revenue,

1198
00:57:01,650 --> 00:57:04,170
but they have a lot of fees--

1199
00:57:04,170 --> 00:57:05,230
a lot of costs.

1200
00:57:05,230 --> 00:57:08,230
They have a ton of employees,
they have a ton of lawyers,

1201
00:57:08,230 --> 00:57:10,015
they have to worry about banks.

1202
00:57:10,015 --> 00:57:11,640
Whereas if you're
like Poloniex-- well,

1203
00:57:11,640 --> 00:57:13,660
Poloniex is now--

1204
00:57:13,660 --> 00:57:17,510
it lasted for like a year or
two where they could do that.

1205
00:57:17,510 --> 00:57:19,680
But if you're just some
random altcoin exchange,

1206
00:57:19,680 --> 00:57:21,090
you don't need a bank account.

1207
00:57:21,090 --> 00:57:23,160
You just say, look,
I'm an exchange where

1208
00:57:23,160 --> 00:57:26,520
you can trade Dogecoin and
Vertcoin, and that's it.

1209
00:57:26,520 --> 00:57:28,110
There's no dollars involved.

1210
00:57:28,110 --> 00:57:30,300
So those kind of
places, they can open up

1211
00:57:30,300 --> 00:57:33,300
on any server,
anywhere in the world.

1212
00:57:33,300 --> 00:57:35,160
They don't even need
to be companies,

1213
00:57:35,160 --> 00:57:37,110
they can just be
someone's server.

1214
00:57:39,780 --> 00:57:42,330
And the fact that
they have custody

1215
00:57:42,330 --> 00:57:44,760
means they keep
getting shut down

1216
00:57:44,760 --> 00:57:47,190
or just running off with money.

1217
00:57:47,190 --> 00:57:50,145
Crypsy-- Crypsy was
that guy, right?

1218
00:57:50,145 --> 00:57:52,580
AUDIENCE: [INAUDIBLE]
exchange wallet

1219
00:57:52,580 --> 00:57:55,160
as like his own
personal bank account.

1220
00:57:55,160 --> 00:57:57,020
Yeah, spent all
the money one day.

1221
00:57:57,020 --> 00:58:00,090
TADGE DRYJA: Right, so--

1222
00:58:00,090 --> 00:58:01,650
and then he said--

1223
00:58:01,650 --> 00:58:04,200
I remember there was a blog
post where he just sort of said

1224
00:58:04,200 --> 00:58:04,860
he did that.

1225
00:58:04,860 --> 00:58:05,310
And it was just like--

1226
00:58:05,310 --> 00:58:06,902
AUDIENCE: He was
trying to justify it.

1227
00:58:06,902 --> 00:58:10,600
Like yeah, we're making fees
and stuff, so it was OK,

1228
00:58:10,600 --> 00:58:14,235
we though we could
[INAUDIBLE] It's

1229
00:58:14,235 --> 00:58:17,200
like where the two graphs
just diverge, unfortunately,

1230
00:58:17,200 --> 00:58:20,057
and it went to zero.

1231
00:58:20,057 --> 00:58:22,140
TADGE DRYJA: But it was
just an amazing blog post,

1232
00:58:22,140 --> 00:58:23,130
where it's like,
wait, you're just

1233
00:58:23,130 --> 00:58:25,170
admitting to a whole
bunch of crimes here,

1234
00:58:25,170 --> 00:58:27,270
you probably shouldn't
have written this.

1235
00:58:27,270 --> 00:58:30,300
And then he fled to China,
but I think they got him.

1236
00:58:30,300 --> 00:58:33,980
He's in jail now or something.

1237
00:58:33,980 --> 00:58:38,010
So there's a lot of you
know pretty bad actors

1238
00:58:38,010 --> 00:58:40,230
in the exchange space.

1239
00:58:40,230 --> 00:58:43,020
It's not well-run generally.

1240
00:58:43,020 --> 00:58:46,500
But there's enormous amounts
of profit, which, to me, seems

1241
00:58:46,500 --> 00:58:47,717
like an inefficiency, right?

1242
00:58:47,717 --> 00:58:49,800
Wait, why are these people
making $1 million a day

1243
00:58:49,800 --> 00:58:53,100
for something that is sort
of just running automatically

1244
00:58:53,100 --> 00:58:53,880
on this computer?

1245
00:58:53,880 --> 00:58:57,540
That seems like
ripe for disruption.

1246
00:58:57,540 --> 00:58:59,610
And so there's a lot of
people interested in, OK,

1247
00:58:59,610 --> 00:59:01,170
how do we decentralize
the exchanges,

1248
00:59:01,170 --> 00:59:06,540
make them less trust-involved,
less risk-involved,

1249
00:59:06,540 --> 00:59:10,620
and probably make less money
than Paloniex, or OK coin,

1250
00:59:10,620 --> 00:59:11,520
or whatever.

1251
00:59:11,520 --> 00:59:15,570
But that's sort of better,
because an exchange where

1252
00:59:15,570 --> 00:59:17,570
there's less profitability
means more people are

1253
00:59:17,570 --> 00:59:20,410
going to want to trade on it
because there's lower fees.

1254
00:59:20,410 --> 00:59:23,620
So there's a lot of
research into this.

1255
00:59:23,620 --> 00:59:26,280
I think it's pretty cool.

1256
00:59:26,280 --> 00:59:28,710
So next class, on
Wednesday, I'll

1257
00:59:28,710 --> 00:59:31,560
talk about discrete
log contracts, which

1258
00:59:31,560 --> 00:59:35,970
share some of these issues,
in that it's a different way

1259
00:59:35,970 --> 00:59:38,220
to execute a trade,
but it doesn't really

1260
00:59:38,220 --> 00:59:41,940
define how you find people
to execute that trade.

1261
00:59:41,940 --> 00:59:44,730
I personally am more interested
in the discrete log contract

1262
00:59:44,730 --> 00:59:47,710
stuff, probably because
I came up with it,

1263
00:59:47,710 --> 00:59:51,940
but also because I'm not
that excited about altcoins

1264
00:59:51,940 --> 00:59:53,725
in general.

1265
00:59:53,725 --> 00:59:55,450
I don't know, people
like altcoins,

1266
00:59:55,450 --> 00:59:57,910
but I don't really
feel that, oh, we

1267
00:59:57,910 --> 01:00:00,580
need to have all these different
altcoins that sort of act

1268
01:00:00,580 --> 01:00:02,180
like money--

1269
01:00:02,180 --> 01:00:04,660
I don't know--
which is mostly what

1270
01:00:04,660 --> 01:00:06,407
cross-chain swaps let you do.

1271
01:00:06,407 --> 01:00:07,990
So the discrete log
contracts, though,

1272
01:00:07,990 --> 01:00:12,130
has the same issues with
how do you find each other.

1273
01:00:12,130 --> 01:00:14,950
And it's mostly a
scalability thing, right?

1274
01:00:14,950 --> 01:00:18,130
You can do this sort of OTC,
where you talk in a chat room,

1275
01:00:18,130 --> 01:00:20,968
and you sort of know each
other, and you trade that way.

1276
01:00:20,968 --> 01:00:22,510
And that's the level
it is right now.

1277
01:00:22,510 --> 01:00:25,590
But how to scale it up
is another question.