WEBVTT Kind: captions Language: en 00:00:01.070 --> 00:00:13.579 align:start position:0% [Applause] 00:00:13.579 --> 00:00:13.589 align:start position:0% 00:00:13.589 --> 00:00:17.249 align:start position:0% yes<00:00:14.589> you'd<00:00:14.799> be<00:00:14.859> fine<00:00:15.070> but<00:00:15.400> but<00:00:16.209> the<00:00:16.720> the<00:00:16.990> mic 00:00:17.249 --> 00:00:17.259 align:start position:0% yes you'd be fine but but the the mic 00:00:17.259 --> 00:00:25.919 align:start position:0% yes you'd be fine but but the the mic would<00:00:17.500> be<00:00:23.820> Lauren<00:00:24.820> look<00:00:25.150> thank<00:00:25.630> you<00:00:25.689> everyone 00:00:25.919 --> 00:00:25.929 align:start position:0% would be Lauren look thank you everyone 00:00:25.929 --> 00:00:28.950 align:start position:0% would be Lauren look thank you everyone for<00:00:26.109> joining<00:00:26.769> this<00:00:27.490> talk<00:00:27.759> and<00:00:28.000> duck<00:00:28.449> mechanics 00:00:28.950 --> 00:00:28.960 align:start position:0% for joining this talk and duck mechanics 00:00:28.960 --> 00:00:31.499 align:start position:0% for joining this talk and duck mechanics I'm<00:00:29.320> the<00:00:29.890> founder<00:00:30.189> of<00:00:30.220> a<00:00:30.369> project<00:00:30.759> called<00:00:31.000> live 00:00:31.499 --> 00:00:31.509 align:start position:0% I'm the founder of a project called live 00:00:31.509 --> 00:00:34.350 align:start position:0% I'm the founder of a project called live here<00:00:31.869> live<00:00:32.500> video<00:00:33.100> streaming<00:00:33.640> infrastructure 00:00:34.350 --> 00:00:34.360 align:start position:0% here live video streaming infrastructure 00:00:34.360 --> 00:00:36.750 align:start position:0% here live video streaming infrastructure project<00:00:34.839> built<00:00:35.470> on<00:00:35.620> interior<00:00:35.860> this<00:00:36.430> is<00:00:36.579> my 00:00:36.750 --> 00:00:36.760 align:start position:0% project built on interior this is my 00:00:36.760 --> 00:00:39.990 align:start position:0% project built on interior this is my colleague<00:00:37.110> youngin<00:00:38.280> who<00:00:39.280> works<00:00:39.579> with<00:00:39.730> us<00:00:39.850> on 00:00:39.990 --> 00:00:40.000 align:start position:0% colleague youngin who works with us on 00:00:40.000 --> 00:00:42.110 align:start position:0% colleague youngin who works with us on protocol<00:00:40.900> design<00:00:41.170> research<00:00:41.590> implementation 00:00:42.110 --> 00:00:42.120 align:start position:0% protocol design research implementation 00:00:42.120 --> 00:00:46.170 align:start position:0% protocol design research implementation we're<00:00:43.120> giving<00:00:43.539> a<00:00:43.600> talk<00:00:43.809> today<00:00:44.079> about<00:00:45.180> scaling 00:00:46.170 --> 00:00:46.180 align:start position:0% we're giving a talk today about scaling 00:00:46.180 --> 00:00:49.799 align:start position:0% we're giving a talk today about scaling payments<00:00:46.840> on<00:00:46.960> etherium<00:00:47.469> using<00:00:48.250> a<00:00:48.809> protocol 00:00:49.799 --> 00:00:49.809 align:start position:0% payments on etherium using a protocol 00:00:49.809 --> 00:00:51.990 align:start position:0% payments on etherium using a protocol called<00:00:49.989> probabilistic<00:00:50.710> micro<00:00:51.309> payments<00:00:51.789> and 00:00:51.990 --> 00:00:52.000 align:start position:0% called probabilistic micro payments and 00:00:52.000 --> 00:00:55.349 align:start position:0% called probabilistic micro payments and the<00:00:52.719> reason<00:00:53.020> that<00:00:53.170> we<00:00:53.320> chose<00:00:53.350> to<00:00:53.920> be<00:00:54.699> into<00:00:55.210> this 00:00:55.349 --> 00:00:55.359 align:start position:0% the reason that we chose to be into this 00:00:55.359 --> 00:00:57.090 align:start position:0% the reason that we chose to be into this protocol<00:00:55.809> and<00:00:55.989> implemented<00:00:56.410> and<00:00:56.530> tested<00:00:56.680> is 00:00:57.090 --> 00:00:57.100 align:start position:0% protocol and implemented and tested is 00:00:57.100 --> 00:01:00.270 align:start position:0% protocol and implemented and tested is because<00:00:57.640> it's<00:00:57.789> actually<00:00:58.239> a<00:00:58.800> scaling<00:00:59.800> solution 00:01:00.270 --> 00:01:00.280 align:start position:0% because it's actually a scaling solution 00:01:00.280 --> 00:01:03.299 align:start position:0% because it's actually a scaling solution for<00:01:00.489> micro<00:01:00.760> payments<00:01:01.239> that<00:01:01.420> works<00:01:01.739> today<00:01:02.739> on 00:01:03.299 --> 00:01:03.309 align:start position:0% for micro payments that works today on 00:01:03.309 --> 00:01:07.020 align:start position:0% for micro payments that works today on ethereum<00:01:03.670> without<00:01:04.570> requiring<00:01:05.080> any<00:01:05.759> layer<00:01:06.759> two 00:01:07.020 --> 00:01:07.030 align:start position:0% ethereum without requiring any layer two 00:01:07.030 --> 00:01:11.070 align:start position:0% ethereum without requiring any layer two solution<00:01:07.630> or<00:01:08.110> any<00:01:08.500> reliance<00:01:08.890> on<00:01:09.390> a<00:01:10.390> trusted 00:01:11.070 --> 00:01:11.080 align:start position:0% solution or any reliance on a trusted 00:01:11.080 --> 00:01:13.740 align:start position:0% solution or any reliance on a trusted third<00:01:11.259> party<00:01:11.679> like<00:01:11.890> a<00:01:11.920> hub<00:01:12.190> so<00:01:13.060> for<00:01:13.300> many<00:01:13.599> use 00:01:13.740 --> 00:01:13.750 align:start position:0% third party like a hub so for many use 00:01:13.750 --> 00:01:15.660 align:start position:0% third party like a hub so for many use cases<00:01:13.780> it's<00:01:14.289> really<00:01:14.979> compelling<00:01:15.310> really 00:01:15.660 --> 00:01:15.670 align:start position:0% cases it's really compelling really 00:01:15.670 --> 00:01:18.449 align:start position:0% cases it's really compelling really powerful<00:01:16.119> there<00:01:16.270> allows<00:01:16.599> you<00:01:16.750> to<00:01:16.869> send<00:01:17.459> micro 00:01:18.449 --> 00:01:18.459 align:start position:0% powerful there allows you to send micro 00:01:18.459 --> 00:01:20.279 align:start position:0% powerful there allows you to send micro payments<00:01:18.880> look<00:01:18.940> around<00:01:19.450> to<00:01:19.720> many<00:01:19.899> receivers 00:01:20.279 --> 00:01:20.289 align:start position:0% payments look around to many receivers 00:01:20.289 --> 00:01:22.680 align:start position:0% payments look around to many receivers without<00:01:21.160> a<00:01:21.190> lot<00:01:21.429> of<00:01:21.520> overhead<00:01:21.759> and<00:01:22.179> without 00:01:22.680 --> 00:01:22.690 align:start position:0% without a lot of overhead and without 00:01:22.690 --> 00:01:25.740 align:start position:0% without a lot of overhead and without exposure<00:01:23.229> to<00:01:23.740> gas<00:01:24.550> price<00:01:24.849> fluctuations<00:01:25.569> in 00:01:25.740 --> 00:01:25.750 align:start position:0% exposure to gas price fluctuations in 00:01:25.750 --> 00:01:27.359 align:start position:0% exposure to gas price fluctuations in the<00:01:25.810> area<00:01:26.140> so<00:01:26.709> I<00:01:26.979> think<00:01:27.069> it's<00:01:27.250> pretty 00:01:27.359 --> 00:01:27.369 align:start position:0% the area so I think it's pretty 00:01:27.369 --> 00:01:31.800 align:start position:0% the area so I think it's pretty interesting<00:01:27.459> so<00:01:28.300> what<00:01:28.569> are<00:01:29.069> PMS<00:01:30.130> I<00:01:30.720> like<00:01:31.720> to 00:01:31.800 --> 00:01:31.810 align:start position:0% interesting so what are PMS I like to 00:01:31.810 --> 00:01:34.770 align:start position:0% interesting so what are PMS I like to think<00:01:31.989> of<00:01:32.080> it<00:01:32.229> as<00:01:32.940> paying<00:01:33.940> for<00:01:34.209> services<00:01:34.720> or 00:01:34.770 --> 00:01:34.780 align:start position:0% think of it as paying for services or 00:01:34.780 --> 00:01:37.440 align:start position:0% think of it as paying for services or content<00:01:35.410> with<00:01:35.530> lottery<00:01:35.860> tickets<00:01:36.250> and<00:01:37.030> a 00:01:37.440 --> 00:01:37.450 align:start position:0% content with lottery tickets and a 00:01:37.450 --> 00:01:39.440 align:start position:0% content with lottery tickets and a traditional<00:01:38.080> kind<00:01:38.500> of<00:01:38.619> micro<00:01:38.950> payment 00:01:39.440 --> 00:01:39.450 align:start position:0% traditional kind of micro payment 00:01:39.450 --> 00:01:41.969 align:start position:0% traditional kind of micro payment solution<00:01:40.450> the<00:01:41.020> mental<00:01:41.319> model<00:01:41.619> that<00:01:41.739> people 00:01:41.969 --> 00:01:41.979 align:start position:0% solution the mental model that people 00:01:41.979 --> 00:01:44.760 align:start position:0% solution the mental model that people have<00:01:42.190> is<00:01:42.429> well<00:01:43.119> you<00:01:43.390> lock<00:01:43.630> some<00:01:44.050> value<00:01:44.739> on 00:01:44.760 --> 00:01:44.770 align:start position:0% have is well you lock some value on 00:01:44.770 --> 00:01:47.580 align:start position:0% have is well you lock some value on chain<00:01:45.220> and<00:01:45.489> so<00:01:46.209> does<00:01:46.330> another<00:01:46.479> party<00:01:46.899> and<00:01:47.170> then 00:01:47.580 --> 00:01:47.590 align:start position:0% chain and so does another party and then 00:01:47.590 --> 00:01:50.490 align:start position:0% chain and so does another party and then you<00:01:47.860> send<00:01:48.550> payments<00:01:49.119> I<00:01:49.360> kind<00:01:50.229> of 00:01:50.490 --> 00:01:50.500 align:start position:0% you send payments I kind of 00:01:50.500 --> 00:01:53.250 align:start position:0% you send payments I kind of cent<00:01:50.980> signatures<00:01:51.430> around<00:01:51.840> option<00:01:52.840> between 00:01:53.250 --> 00:01:53.260 align:start position:0% cent signatures around option between 00:01:53.260 --> 00:01:54.570 align:start position:0% cent signatures around option between these<00:01:53.380> two<00:01:53.530> parties<00:01:53.830> and<00:01:54.010> they<00:01:54.070> keep<00:01:54.190> track<00:01:54.370> of 00:01:54.570 --> 00:01:54.580 align:start position:0% these two parties and they keep track of 00:01:54.580 --> 00:01:56.070 align:start position:0% these two parties and they keep track of the<00:01:54.640> balance<00:01:55.060> and<00:01:55.210> then<00:01:55.660> when<00:01:55.780> someone's 00:01:56.070 --> 00:01:56.080 align:start position:0% the balance and then when someone's 00:01:56.080 --> 00:01:57.660 align:start position:0% the balance and then when someone's ready<00:01:56.230> to<00:01:56.380> leave<00:01:56.560> and<00:01:56.830> cash<00:01:57.040> out<00:01:57.280> and<00:01:57.550> take 00:01:57.660 --> 00:01:57.670 align:start position:0% ready to leave and cash out and take 00:01:57.670 --> 00:01:59.310 align:start position:0% ready to leave and cash out and take their<00:01:57.850> payment<00:01:58.240> they<00:01:58.720> submit<00:01:59.050> the<00:01:59.170> proof 00:01:59.310 --> 00:01:59.320 align:start position:0% their payment they submit the proof 00:01:59.320 --> 00:02:02.460 align:start position:0% their payment they submit the proof unchain<00:01:59.740> and<00:02:00.100> leave<00:02:00.510> and<00:02:01.510> kind<00:02:01.900> of<00:02:01.930> close<00:02:02.170> the 00:02:02.460 --> 00:02:02.470 align:start position:0% unchain and leave and kind of close the 00:02:02.470 --> 00:02:05.730 align:start position:0% unchain and leave and kind of close the closure<00:02:03.220> channel<00:02:03.840> so<00:02:04.840> it<00:02:05.020> probabilistic 00:02:05.730 --> 00:02:05.740 align:start position:0% closure channel so it probabilistic 00:02:05.740 --> 00:02:07.020 align:start position:0% closure channel so it probabilistic micro<00:02:06.010> payments<00:02:06.400> or<00:02:06.490> you're<00:02:06.580> paying<00:02:06.760> fiery 00:02:07.020 --> 00:02:07.030 align:start position:0% micro payments or you're paying fiery 00:02:07.030 --> 00:02:08.639 align:start position:0% micro payments or you're paying fiery tickets<00:02:07.450> it's<00:02:07.570> a<00:02:07.660> totally<00:02:08.050> different<00:02:08.080> mental 00:02:08.639 --> 00:02:08.649 align:start position:0% tickets it's a totally different mental 00:02:08.649 --> 00:02:10.560 align:start position:0% tickets it's a totally different mental model<00:02:08.710> it's<00:02:09.550> thinking<00:02:09.820> if<00:02:09.940> you<00:02:10.090> are<00:02:10.119> going<00:02:10.509> to 00:02:10.560 --> 00:02:10.570 align:start position:0% model it's thinking if you are going to 00:02:10.570 --> 00:02:13.200 align:start position:0% model it's thinking if you are going to be<00:02:10.720> paying<00:02:10.960> someone<00:02:11.380> or<00:02:11.710> people<00:02:12.190> what<00:02:12.940> you<00:02:13.030> do 00:02:13.200 --> 00:02:13.210 align:start position:0% be paying someone or people what you do 00:02:13.210 --> 00:02:16.400 align:start position:0% be paying someone or people what you do is<00:02:13.360> you<00:02:13.540> run<00:02:13.810> a<00:02:13.840> continuous<00:02:14.560> lottery<00:02:15.010> and 00:02:16.400 --> 00:02:16.410 align:start position:0% is you run a continuous lottery and 00:02:16.410 --> 00:02:19.200 align:start position:0% is you run a continuous lottery and everyone<00:02:17.410> who<00:02:17.770> you're<00:02:18.310> paying<00:02:18.490> your<00:02:18.760> decision 00:02:19.200 --> 00:02:19.210 align:start position:0% everyone who you're paying your decision 00:02:19.210 --> 00:02:20.700 align:start position:0% everyone who you're paying your decision lottery<00:02:19.570> tickets<00:02:19.960> to<00:02:20.110> the<00:02:20.260> playing<00:02:20.560> the 00:02:20.700 --> 00:02:20.710 align:start position:0% lottery tickets to the playing the 00:02:20.710 --> 00:02:23.850 align:start position:0% lottery tickets to the playing the lottery<00:02:20.980> against<00:02:21.970> you<00:02:22.090> and<00:02:22.709> eventually<00:02:23.709> some 00:02:23.850 --> 00:02:23.860 align:start position:0% lottery against you and eventually some 00:02:23.860 --> 00:02:25.890 align:start position:0% lottery against you and eventually some of<00:02:23.950> those<00:02:24.070> tickets<00:02:24.430> become<00:02:24.790> winners<00:02:25.030> and<00:02:25.510> the 00:02:25.890 --> 00:02:25.900 align:start position:0% of those tickets become winners and the 00:02:25.900 --> 00:02:27.570 align:start position:0% of those tickets become winners and the recipients<00:02:26.500> get<00:02:26.650> to<00:02:26.800> cash<00:02:26.980> in<00:02:27.220> the<00:02:27.310> winning 00:02:27.570 --> 00:02:27.580 align:start position:0% recipients get to cash in the winning 00:02:27.580 --> 00:02:29.580 align:start position:0% recipients get to cash in the winning tickets<00:02:27.940> on<00:02:28.090> unit<00:02:28.450> to<00:02:28.570> receive<00:02:28.840> their<00:02:29.080> their 00:02:29.580 --> 00:02:29.590 align:start position:0% tickets on unit to receive their their 00:02:29.590 --> 00:02:32.370 align:start position:0% tickets on unit to receive their their payments<00:02:30.040> so<00:02:30.640> this<00:02:31.240> colloquy<00:02:31.600> in<00:02:31.870> a<00:02:31.959> kind<00:02:32.350> of 00:02:32.370 --> 00:02:32.380 align:start position:0% payments so this colloquy in a kind of 00:02:32.380 --> 00:02:35.310 align:start position:0% payments so this colloquy in a kind of good<00:02:32.680> overview<00:02:33.070> of<00:02:33.220> PM's<00:02:33.610> and<00:02:34.320> scalable 00:02:35.310 --> 00:02:35.320 align:start position:0% good overview of PM's and scalable 00:02:35.320 --> 00:02:36.660 align:start position:0% good overview of PM's and scalable payment<00:02:35.620> requirements<00:02:36.160> talked<00:02:36.310> about<00:02:36.520> other 00:02:36.660 --> 00:02:36.670 align:start position:0% payment requirements talked about other 00:02:36.670 --> 00:02:39.960 align:start position:0% payment requirements talked about other men<00:02:37.080> we're<00:02:38.080> going<00:02:38.110> to<00:02:38.260> compare<00:02:38.560> it<00:02:38.590> to<00:02:39.070> payment 00:02:39.960 --> 00:02:39.970 align:start position:0% men we're going to compare it to payment 00:02:39.970 --> 00:02:42.210 align:start position:0% men we're going to compare it to payment channels<00:02:40.290> we'll<00:02:41.290> talk<00:02:41.560> about<00:02:41.680> the<00:02:41.860> security 00:02:42.210 --> 00:02:42.220 align:start position:0% channels we'll talk about the security 00:02:42.220 --> 00:02:45.360 align:start position:0% channels we'll talk about the security models<00:02:42.760> and<00:02:43.660> how<00:02:43.930> you<00:02:43.990> secure<00:02:44.530> these<00:02:44.770> systems 00:02:45.360 --> 00:02:45.370 align:start position:0% models and how you secure these systems 00:02:45.370 --> 00:02:47.910 align:start position:0% models and how you secure these systems he<00:02:45.490> has<00:02:45.580> double<00:02:45.850> spends<00:02:46.350> and<00:02:47.350> finally<00:02:47.740> we'll 00:02:47.910 --> 00:02:47.920 align:start position:0% he has double spends and finally we'll 00:02:47.920 --> 00:02:49.640 align:start position:0% he has double spends and finally we'll give<00:02:48.070> a<00:02:48.100> quick<00:02:48.340> look<00:02:48.550> into<00:02:48.880> our 00:02:49.640 --> 00:02:49.650 align:start position:0% give a quick look into our 00:02:49.650 --> 00:02:52.500 align:start position:0% give a quick look into our implementation<00:02:50.970> some<00:02:51.970> benchmarks<00:02:52.450> that 00:02:52.500 --> 00:02:52.510 align:start position:0% implementation some benchmarks that 00:02:52.510 --> 00:02:56.820 align:start position:0% implementation some benchmarks that we've<00:02:52.720> seen<00:02:53.550> running<00:02:54.550> this<00:02:54.670> and<00:02:55.650> point<00:02:56.650> to<00:02:56.739> the 00:02:56.820 --> 00:02:56.830 align:start position:0% we've seen running this and point to the 00:02:56.830 --> 00:03:02.310 align:start position:0% we've seen running this and point to the open<00:02:57.040> source<00:02:57.220> code<00:02:59.670> cool<00:03:00.670> okay<00:03:01.000> so<00:03:01.260> there's<00:03:02.260> a 00:03:02.310 --> 00:03:02.320 align:start position:0% open source code cool okay so there's a 00:03:02.320 --> 00:03:04.440 align:start position:0% open source code cool okay so there's a measure<00:03:02.470> the<00:03:02.680> model<00:03:02.950> here<00:03:03.070> is<00:03:03.160> a<00:03:03.280> sender<00:03:03.790> needs 00:03:04.440 --> 00:03:04.450 align:start position:0% measure the model here is a sender needs 00:03:04.450 --> 00:03:07.140 align:start position:0% measure the model here is a sender needs to<00:03:04.690> send<00:03:04.959> some<00:03:05.350> value<00:03:05.800> to<00:03:05.890> a<00:03:06.190> recipient<00:03:06.760> in 00:03:07.140 --> 00:03:07.150 align:start position:0% to send some value to a recipient in 00:03:07.150 --> 00:03:08.820 align:start position:0% to send some value to a recipient in exchange<00:03:07.630> for<00:03:07.660> some<00:03:07.930> service<00:03:08.320> or<00:03:08.530> some 00:03:08.820 --> 00:03:08.830 align:start position:0% exchange for some service or some 00:03:08.830 --> 00:03:11.820 align:start position:0% exchange for some service or some content<00:03:09.310> so<00:03:09.930> you<00:03:10.930> could<00:03:11.050> think<00:03:11.170> of<00:03:11.320> it<00:03:11.500> as<00:03:11.650> if 00:03:11.820 --> 00:03:11.830 align:start position:0% content so you could think of it as if 00:03:11.830 --> 00:03:14.070 align:start position:0% content so you could think of it as if you're<00:03:11.980> streaming<00:03:12.220> music<00:03:12.550> you<00:03:13.510> might<00:03:13.810> want<00:03:14.019> to 00:03:14.070 --> 00:03:14.080 align:start position:0% you're streaming music you might want to 00:03:14.080 --> 00:03:15.509 align:start position:0% you're streaming music you might want to be<00:03:14.200> sending<00:03:14.440> a<00:03:14.620> pan<00:03:14.800> in<00:03:14.950> every<00:03:15.160> couple<00:03:15.430> of 00:03:15.509 --> 00:03:15.519 align:start position:0% be sending a pan in every couple of 00:03:15.519 --> 00:03:18.780 align:start position:0% be sending a pan in every couple of seconds<00:03:16.510> to<00:03:16.750> the<00:03:17.280> person<00:03:18.280> who's<00:03:18.370> providing 00:03:18.780 --> 00:03:18.790 align:start position:0% seconds to the person who's providing 00:03:18.790 --> 00:03:21.710 align:start position:0% seconds to the person who's providing music<00:03:19.180> in<00:03:19.810> our<00:03:19.989> case<00:03:20.290> in<00:03:20.530> my<00:03:20.680> view<00:03:20.980> you're 00:03:21.710 --> 00:03:21.720 align:start position:0% music in our case in my view you're 00:03:21.720 --> 00:03:26.590 align:start position:0% music in our case in my view you're encoding<00:03:22.720> video<00:03:23.200> and<00:03:23.650> you're<00:03:24.370> paying<00:03:24.790> the 00:03:26.590 --> 00:03:26.600 align:start position:0% encoding video and you're paying the 00:03:26.600 --> 00:03:31.070 align:start position:0% encoding video and you're paying the fly<00:03:27.710> so<00:03:28.760> as<00:03:29.760> I<00:03:29.880> mentioned<00:03:30.240> instead<00:03:30.750> of<00:03:30.840> sending 00:03:31.070 --> 00:03:31.080 align:start position:0% fly so as I mentioned instead of sending 00:03:31.080 --> 00:03:33.470 align:start position:0% fly so as I mentioned instead of sending an<00:03:31.410> actual<00:03:31.800> value<00:03:31.920> doing<00:03:32.550> either<00:03:32.880> transfer 00:03:33.470 --> 00:03:33.480 align:start position:0% an actual value doing either transfer 00:03:33.480 --> 00:03:35.630 align:start position:0% an actual value doing either transfer what<00:03:34.050> you<00:03:34.140> do<00:03:34.290> is<00:03:34.410> you<00:03:34.560> send<00:03:34.830> to<00:03:35.040> this<00:03:35.160> kind<00:03:35.430> off 00:03:35.630 --> 00:03:35.640 align:start position:0% what you do is you send to this kind off 00:03:35.640 --> 00:03:37.670 align:start position:0% what you do is you send to this kind off chain<00:03:35.940> lottery<00:03:36.300> ticket<00:03:36.690> to<00:03:37.050> the<00:03:37.140> recipient 00:03:37.670 --> 00:03:37.680 align:start position:0% chain lottery ticket to the recipient 00:03:37.680 --> 00:03:41.000 align:start position:0% chain lottery ticket to the recipient and<00:03:38.010> the<00:03:38.430> recipient<00:03:39.000> checks<00:03:39.270> to<00:03:40.230> see<00:03:40.500> if<00:03:40.890> the 00:03:41.000 --> 00:03:41.010 align:start position:0% and the recipient checks to see if the 00:03:41.010 --> 00:03:43.250 align:start position:0% and the recipient checks to see if the ticket<00:03:41.610> is<00:03:41.700> a<00:03:41.880> winner<00:03:42.120> and<00:03:42.420> if<00:03:42.900> it's<00:03:43.050> not<00:03:43.200> a 00:03:43.250 --> 00:03:43.260 align:start position:0% ticket is a winner and if it's not a 00:03:43.260 --> 00:03:43.900 align:start position:0% ticket is a winner and if it's not a winner 00:03:43.900 --> 00:03:43.910 align:start position:0% winner 00:03:43.910 --> 00:03:47.030 align:start position:0% winner they<00:03:44.910> just<00:03:45.209> discard<00:03:45.930> the<00:03:46.140> ticket<00:03:46.500> it's<00:03:46.800> worth 00:03:47.030 --> 00:03:47.040 align:start position:0% they just discard the ticket it's worth 00:03:47.040 --> 00:03:47.480 align:start position:0% they just discard the ticket it's worth zero 00:03:47.480 --> 00:03:47.490 align:start position:0% zero 00:03:47.490 --> 00:03:50.090 align:start position:0% zero they<00:03:47.700> went<00:03:47.880> to<00:03:48.000> cash<00:03:48.180> it<00:03:48.360> in<00:03:48.480> on<00:03:48.660> Channel<00:03:49.110> and 00:03:50.090 --> 00:03:50.100 align:start position:0% they went to cash it in on Channel and 00:03:50.100 --> 00:03:51.620 align:start position:0% they went to cash it in on Channel and this<00:03:50.280> is<00:03:50.459> kind<00:03:50.760> of<00:03:50.790> the<00:03:50.880> default<00:03:51.000> case<00:03:51.360> this 00:03:51.620 --> 00:03:51.630 align:start position:0% this is kind of the default case this 00:03:51.630 --> 00:03:55.040 align:start position:0% this is kind of the default case this happens<00:03:51.930> most<00:03:52.170> of<00:03:52.350> the<00:03:52.410> time<00:03:52.740> but<00:03:53.930> when<00:03:54.930> they 00:03:55.040 --> 00:03:55.050 align:start position:0% happens most of the time but when they 00:03:55.050 --> 00:03:57.199 align:start position:0% happens most of the time but when they get<00:03:55.140> a<00:03:55.200> ticket<00:03:55.620> the<00:03:55.980> ticket<00:03:56.010> may<00:03:56.430> be<00:03:56.490> a<00:03:56.580> winner 00:03:57.199 --> 00:03:57.209 align:start position:0% get a ticket the ticket may be a winner 00:03:57.209 --> 00:04:01.880 align:start position:0% get a ticket the ticket may be a winner and<00:03:57.600> it's<00:03:57.840> a<00:03:57.900> winner<00:03:58.110> it's<00:03:58.620> worth<00:03:59.480> if<00:04:00.480> and<00:04:00.890> in 00:04:01.880 --> 00:04:01.890 align:start position:0% and it's a winner it's worth if and in 00:04:01.890 --> 00:04:04.070 align:start position:0% and it's a winner it's worth if and in this<00:04:01.980> case<00:04:02.220> they<00:04:02.730> just<00:04:02.790> catch<00:04:03.300> that<00:04:03.330> ticket<00:04:03.930> in 00:04:04.070 --> 00:04:04.080 align:start position:0% this case they just catch that ticket in 00:04:04.080 --> 00:04:09.800 align:start position:0% this case they just catch that ticket in on<00:04:04.380> Chan<00:04:04.709> to<00:04:05.340> redeem<00:04:05.610> their<00:04:05.820> winnings<00:04:06.180> and<00:04:08.810> the 00:04:09.800 --> 00:04:09.810 align:start position:0% on Chan to redeem their winnings and the 00:04:09.810 --> 00:04:11.090 align:start position:0% on Chan to redeem their winnings and the kind<00:04:10.110> of<00:04:10.140> interesting<00:04:10.500> thing<00:04:10.680> the<00:04:10.800> way<00:04:10.890> this 00:04:11.090 --> 00:04:11.100 align:start position:0% kind of interesting thing the way this 00:04:11.100 --> 00:04:13.040 align:start position:0% kind of interesting thing the way this works<00:04:11.340> is<00:04:11.580> if<00:04:11.850> you<00:04:11.880> think<00:04:12.000> it's<00:04:12.270> a<00:04:12.330> lottery<00:04:12.660> a 00:04:13.040 --> 00:04:13.050 align:start position:0% works is if you think it's a lottery a 00:04:13.050 --> 00:04:15.560 align:start position:0% works is if you think it's a lottery a lottery<00:04:13.650> ticket<00:04:13.800> has<00:04:14.040> an<00:04:14.160> expected<00:04:14.640> value<00:04:14.670> you 00:04:15.560 --> 00:04:15.570 align:start position:0% lottery ticket has an expected value you 00:04:15.570 --> 00:04:16.789 align:start position:0% lottery ticket has an expected value you know<00:04:15.720> that<00:04:15.870> if<00:04:15.959> you<00:04:16.049> win<00:04:16.200> the<00:04:16.320> jackpot 00:04:16.789 --> 00:04:16.799 align:start position:0% know that if you win the jackpot 00:04:16.799 --> 00:04:19.069 align:start position:0% know that if you win the jackpot you<00:04:17.519> know<00:04:17.640> in<00:04:17.940> the<00:04:18.030> real<00:04:18.359> world<00:04:18.510> lottery<00:04:18.870> it's 00:04:19.069 --> 00:04:19.079 align:start position:0% you know in the real world lottery it's 00:04:19.079 --> 00:04:21.319 align:start position:0% you know in the real world lottery it's going<00:04:19.230> to<00:04:19.290> be<00:04:19.410> 100<00:04:20.160> million<00:04:20.430> dollars<00:04:20.850> but<00:04:21.239> you 00:04:21.319 --> 00:04:21.329 align:start position:0% going to be 100 million dollars but you 00:04:21.329 --> 00:04:23.360 align:start position:0% going to be 100 million dollars but you know<00:04:21.450> the<00:04:21.570> odds<00:04:21.750> of<00:04:22.079> winning<00:04:22.169> the<00:04:22.350> jackpot<00:04:22.410> are 00:04:23.360 --> 00:04:23.370 align:start position:0% know the odds of winning the jackpot are 00:04:23.370 --> 00:04:26.150 align:start position:0% know the odds of winning the jackpot are say<00:04:23.700> you<00:04:24.660> know<00:04:24.780> one<00:04:25.470> in<00:04:25.620> a<00:04:25.650> hundred<00:04:25.770> million 00:04:26.150 --> 00:04:26.160 align:start position:0% say you know one in a hundred million 00:04:26.160 --> 00:04:28.850 align:start position:0% say you know one in a hundred million and<00:04:26.490> therefore<00:04:27.210> you<00:04:27.630> can<00:04:27.870> calculate<00:04:28.380> all<00:04:28.680> the 00:04:28.850 --> 00:04:28.860 align:start position:0% and therefore you can calculate all the 00:04:28.860 --> 00:04:31.520 align:start position:0% and therefore you can calculate all the expected<00:04:29.400> value<00:04:29.669> of<00:04:29.700> this<00:04:29.850> ticket<00:04:30.090> is<00:04:30.300> $1<00:04:30.720> so 00:04:31.520 --> 00:04:31.530 align:start position:0% expected value of this ticket is $1 so 00:04:31.530 --> 00:04:33.590 align:start position:0% expected value of this ticket is $1 so here<00:04:32.190> with<00:04:32.400> probabilistic<00:04:32.729> micropayments<00:04:33.330> it 00:04:33.590 --> 00:04:33.600 align:start position:0% here with probabilistic micropayments it 00:04:33.600 --> 00:04:36.080 align:start position:0% here with probabilistic micropayments it works<00:04:33.750> the<00:04:33.900> same<00:04:34.080> way<00:04:34.320> the<00:04:35.250> ticket<00:04:35.700> in<00:04:35.970> this 00:04:36.080 --> 00:04:36.090 align:start position:0% works the same way the ticket in this 00:04:36.090 --> 00:04:39.170 align:start position:0% works the same way the ticket in this case<00:04:36.300> as<00:04:36.570> a<00:04:36.600> face<00:04:36.840> value<00:04:36.960> of<00:04:37.260> 1/8<00:04:38.220> doing 00:04:39.170 --> 00:04:39.180 align:start position:0% case as a face value of 1/8 doing 00:04:39.180 --> 00:04:40.820 align:start position:0% case as a face value of 1/8 doing probability<00:04:39.840> could<00:04:40.050> be<00:04:40.169> set<00:04:40.380> to<00:04:40.500> one<00:04:40.680> in<00:04:40.770> a 00:04:40.820 --> 00:04:40.830 align:start position:0% probability could be set to one in a 00:04:40.830 --> 00:04:43.340 align:start position:0% probability could be set to one in a thousand<00:04:41.250> and<00:04:41.460> so<00:04:41.940> the<00:04:42.030> recipient<00:04:42.390> knows<00:04:42.690> well 00:04:43.340 --> 00:04:43.350 align:start position:0% thousand and so the recipient knows well 00:04:43.350 --> 00:04:45.560 align:start position:0% thousand and so the recipient knows well this<00:04:43.470> is<00:04:43.590> worth<00:04:43.800> a<00:04:44.070> thousand<00:04:44.580> seventeen<00:04:45.000> and 00:04:45.560 --> 00:04:45.570 align:start position:0% this is worth a thousand seventeen and 00:04:45.570 --> 00:04:47.330 align:start position:0% this is worth a thousand seventeen and they're<00:04:45.990> willing<00:04:46.260> to<00:04:46.320> do<00:04:46.560> as<00:04:46.680> much<00:04:46.830> work<00:04:46.890> as 00:04:47.330 --> 00:04:47.340 align:start position:0% they're willing to do as much work as 00:04:47.340 --> 00:04:48.719 align:start position:0% they're willing to do as much work as they<00:04:47.520> want<00:04:47.760> to<00:04:47.850> do 00:04:48.719 --> 00:04:48.729 align:start position:0% they want to do 00:04:48.729 --> 00:04:50.969 align:start position:0% they want to do I<00:04:48.759> mean<00:04:48.969> or<00:04:49.689> provide<00:04:50.020> as<00:04:50.139> much<00:04:50.289> content<00:04:50.770> that 00:04:50.969 --> 00:04:50.979 align:start position:0% I mean or provide as much content that 00:04:50.979 --> 00:04:52.230 align:start position:0% I mean or provide as much content that would<00:04:51.099> provide<00:04:51.339> for<00:04:51.400> a<00:04:51.610> thousandth<00:04:52.059> of<00:04:52.120> it 00:04:52.230 --> 00:04:52.240 align:start position:0% would provide for a thousandth of it 00:04:52.240 --> 00:04:55.589 align:start position:0% would provide for a thousandth of it even<00:04:52.499> and<00:04:53.729> the<00:04:54.729> second<00:04:55.089> example 00:04:55.589 --> 00:04:55.599 align:start position:0% even and the second example 00:04:55.599 --> 00:04:59.189 align:start position:0% even and the second example it<00:04:56.409> as<00:04:56.680> a<00:04:56.740> different<00:04:57.069> face<00:04:57.219> value<00:04:57.669> teni<00:04:58.240> and<00:04:58.960> we 00:04:59.189 --> 00:04:59.199 align:start position:0% it as a different face value teni and we 00:04:59.199 --> 00:05:01.379 align:start position:0% it as a different face value teni and we probability<00:04:59.740> of<00:04:59.800> one<00:04:59.919> in<00:04:59.949> 10,000<00:05:00.699> but<00:05:01.210> the 00:05:01.379 --> 00:05:01.389 align:start position:0% probability of one in 10,000 but the 00:05:01.389 --> 00:05:03.659 align:start position:0% probability of one in 10,000 but the expected<00:05:02.229> value<00:05:02.770> of<00:05:02.800> the<00:05:02.949> ticket<00:05:03.069> is<00:05:03.279> the<00:05:03.309> same 00:05:03.659 --> 00:05:03.669 align:start position:0% expected value of the ticket is the same 00:05:03.669 --> 00:05:07.230 align:start position:0% expected value of the ticket is the same it's<00:05:04.210> one<00:05:04.659> thousandth<00:05:05.289> of<00:05:05.379> any<00:05:05.589> and<00:05:06.240> what's 00:05:07.230 --> 00:05:07.240 align:start position:0% it's one thousandth of any and what's 00:05:07.240 --> 00:05:09.659 align:start position:0% it's one thousandth of any and what's powerful<00:05:07.599> about<00:05:07.809> this<00:05:08.199> kind<00:05:08.860> of<00:05:08.919> mechanic<00:05:09.460> is 00:05:09.659 --> 00:05:09.669 align:start position:0% powerful about this kind of mechanic is 00:05:09.669 --> 00:05:12.749 align:start position:0% powerful about this kind of mechanic is that<00:05:10.180> because<00:05:10.629> a<00:05:11.249> recipient<00:05:12.249> can<00:05:12.460> tell<00:05:12.639> us 00:05:12.749 --> 00:05:12.759 align:start position:0% that because a recipient can tell us 00:05:12.759 --> 00:05:14.519 align:start position:0% that because a recipient can tell us under<00:05:13.120> what<00:05:13.360> they<00:05:13.479> want<00:05:13.659> these<00:05:13.809> parameters<00:05:14.379> to 00:05:14.519 --> 00:05:14.529 align:start position:0% under what they want these parameters to 00:05:14.529 --> 00:05:19.670 align:start position:0% under what they want these parameters to be<00:05:15.029> they<00:05:16.029> can<00:05:16.210> actually<00:05:16.749> control<00:05:18.089> kind<00:05:19.089> of<00:05:19.180> the 00:05:19.670 --> 00:05:19.680 align:start position:0% be they can actually control kind of the 00:05:19.680 --> 00:05:22.260 align:start position:0% be they can actually control kind of the overhead<00:05:20.680> that<00:05:20.949> they<00:05:21.219> have<00:05:21.370> to<00:05:21.490> pay<00:05:21.699> in<00:05:22.120> order 00:05:22.260 --> 00:05:22.270 align:start position:0% overhead that they have to pay in order 00:05:22.270 --> 00:05:24.420 align:start position:0% overhead that they have to pay in order to<00:05:22.479> cash<00:05:22.719> these<00:05:23.110> tickets<00:05:23.770> in<00:05:23.919> a<00:05:23.949> routine<00:05:24.219> them 00:05:24.420 --> 00:05:24.430 align:start position:0% to cash these tickets in a routine them 00:05:24.430 --> 00:05:26.760 align:start position:0% to cash these tickets in a routine them on<00:05:24.550> the<00:05:24.669> blockchain<00:05:24.879> and<00:05:25.449> so<00:05:26.229> what<00:05:26.379> that<00:05:26.499> means 00:05:26.760 --> 00:05:26.770 align:start position:0% on the blockchain and so what that means 00:05:26.770 --> 00:05:29.790 align:start position:0% on the blockchain and so what that means is<00:05:27.279> if<00:05:28.240> gas<00:05:28.479> prices<00:05:28.509> are<00:05:28.990> really<00:05:29.110> low<00:05:29.229> you 00:05:29.790 --> 00:05:29.800 align:start position:0% is if gas prices are really low you 00:05:29.800 --> 00:05:33.149 align:start position:0% is if gas prices are really low you could<00:05:30.749> say<00:05:31.749> oh<00:05:31.779> I'm<00:05:31.990> willing<00:05:32.229> to<00:05:32.259> accept<00:05:32.589> one 00:05:33.149 --> 00:05:33.159 align:start position:0% could say oh I'm willing to accept one 00:05:33.159 --> 00:05:35.279 align:start position:0% could say oh I'm willing to accept one Eve<00:05:33.339> its<00:05:33.759> value<00:05:34.210> tickets<00:05:34.569> or<00:05:34.809> even<00:05:35.080> less 00:05:35.279 --> 00:05:35.289 align:start position:0% Eve its value tickets or even less 00:05:35.289 --> 00:05:37.320 align:start position:0% Eve its value tickets or even less because<00:05:36.219> I<00:05:36.309> can<00:05:36.460> cash<00:05:36.669> them<00:05:36.819> in<00:05:36.939> it<00:05:37.089> doesn't 00:05:37.320 --> 00:05:37.330 align:start position:0% because I can cash them in it doesn't 00:05:37.330 --> 00:05:39.209 align:start position:0% because I can cash them in it doesn't cost<00:05:37.449> me<00:05:37.659> a<00:05:37.689> lot<00:05:37.839> but<00:05:38.379> when<00:05:38.469> gas<00:05:38.649> prices<00:05:38.680> rise 00:05:39.209 --> 00:05:39.219 align:start position:0% cost me a lot but when gas prices rise 00:05:39.219 --> 00:05:40.529 align:start position:0% cost me a lot but when gas prices rise you<00:05:39.490> can<00:05:39.520> say<00:05:39.729> well<00:05:40.120> I<00:05:40.149> don't<00:05:40.300> want<00:05:40.419> to<00:05:40.479> be 00:05:40.529 --> 00:05:40.539 align:start position:0% you can say well I don't want to be 00:05:40.539 --> 00:05:42.029 align:start position:0% you can say well I don't want to be doing<00:05:40.659> a<00:05:40.749> lot<00:05:40.839> of<00:05:40.960> transactions<00:05:41.559> to<00:05:41.620> cash<00:05:41.860> in 00:05:42.029 --> 00:05:42.039 align:start position:0% doing a lot of transactions to cash in 00:05:42.039 --> 00:05:44.909 align:start position:0% doing a lot of transactions to cash in these<00:05:42.159> tickets<00:05:42.550> I'm<00:05:42.969> going<00:05:43.419> to<00:05:43.770> change<00:05:44.770> the 00:05:44.909 --> 00:05:44.919 align:start position:0% these tickets I'm going to change the 00:05:44.919 --> 00:05:46.439 align:start position:0% these tickets I'm going to change the parameters<00:05:45.279> around<00:05:45.580> cash<00:05:45.909> them<00:05:46.089> in<00:05:46.180> less<00:05:46.330> than 00:05:46.439 --> 00:05:46.449 align:start position:0% parameters around cash them in less than 00:05:46.449 --> 00:05:50.489 align:start position:0% parameters around cash them in less than frequently<00:05:46.990> and<00:05:47.339> still<00:05:48.749> earn<00:05:49.749> the<00:05:50.259> same 00:05:50.489 --> 00:05:50.499 align:start position:0% frequently and still earn the same 00:05:50.499 --> 00:05:52.529 align:start position:0% frequently and still earn the same amount<00:05:50.860> of<00:05:51.339> value<00:05:51.639> that<00:05:51.699> I<00:05:51.819> expected<00:05:52.240> to<00:05:52.300> earn 00:05:52.529 --> 00:05:52.539 align:start position:0% amount of value that I expected to earn 00:05:52.539 --> 00:05:54.959 align:start position:0% amount of value that I expected to earn so<00:05:53.199> what's<00:05:53.800> cool<00:05:54.009> is<00:05:54.069> it<00:05:54.310> lets<00:05:54.490> you<00:05:54.580> control 00:05:54.959 --> 00:05:54.969 align:start position:0% so what's cool is it lets you control 00:05:54.969 --> 00:05:59.309 align:start position:0% so what's cool is it lets you control how<00:05:55.539> much<00:05:56.349> overhead<00:05:56.789> you<00:05:57.789> have<00:05:58.599> in<00:05:58.810> cashing<00:05:59.199> in 00:05:59.309 --> 00:05:59.319 align:start position:0% how much overhead you have in cashing in 00:05:59.319 --> 00:06:00.510 align:start position:0% how much overhead you have in cashing in tickets<00:05:59.620> because<00:05:59.740> I'm<00:05:59.949> never<00:06:00.159> going<00:06:00.339> to<00:06:00.370> pay 00:06:00.510 --> 00:06:00.520 align:start position:0% tickets because I'm never going to pay 00:06:00.520 --> 00:06:02.879 align:start position:0% tickets because I'm never going to pay more<00:06:00.789> than<00:06:00.939> one<00:06:01.120> percent<00:06:01.509> of<00:06:01.810> my<00:06:02.229> earnings<00:06:02.649> to 00:06:02.879 --> 00:06:02.889 align:start position:0% more than one percent of my earnings to 00:06:02.889 --> 00:06:04.920 align:start position:0% more than one percent of my earnings to use<00:06:03.279> the<00:06:03.430> blockchain<00:06:03.669> to<00:06:04.089> cash<00:06:04.270> in<00:06:04.509> tickets 00:06:04.920 --> 00:06:04.930 align:start position:0% use the blockchain to cash in tickets 00:06:04.930 --> 00:06:08.100 align:start position:0% use the blockchain to cash in tickets and<00:06:05.370> you<00:06:06.370> had<00:06:06.490> to<00:06:06.610> control<00:06:06.969> that<00:06:07.180> regardless 00:06:08.100 --> 00:06:08.110 align:start position:0% and you had to control that regardless 00:06:08.110 --> 00:06:10.800 align:start position:0% and you had to control that regardless of<00:06:08.229> where<00:06:08.469> at<00:06:08.620> their<00:06:08.770> gas<00:06:09.069> prices<00:06:09.520> go<00:06:09.810> that's 00:06:10.800 --> 00:06:10.810 align:start position:0% of where at their gas prices go that's 00:06:10.810 --> 00:06:12.719 align:start position:0% of where at their gas prices go that's pretty<00:06:10.930> powerful<00:06:11.199> that<00:06:11.649> 1%<00:06:11.949> example<00:06:12.550> is<00:06:12.639> just 00:06:12.719 --> 00:06:12.729 align:start position:0% pretty powerful that 1% example is just 00:06:12.729 --> 00:06:13.889 align:start position:0% pretty powerful that 1% example is just the<00:06:12.849> number<00:06:13.029> I<00:06:13.060> made<00:06:13.240> up<00:06:13.360> but<00:06:13.509> if<00:06:13.599> you<00:06:13.659> think<00:06:13.779> of 00:06:13.889 --> 00:06:13.899 align:start position:0% the number I made up but if you think of 00:06:13.899 --> 00:06:15.659 align:start position:0% the number I made up but if you think of accepting<00:06:14.259> a<00:06:14.379> credit<00:06:14.709> card<00:06:14.830> for<00:06:15.069> example<00:06:15.189> as<00:06:15.639> a 00:06:15.659 --> 00:06:15.669 align:start position:0% accepting a credit card for example as a 00:06:15.669 --> 00:06:17.820 align:start position:0% accepting a credit card for example as a merchant<00:06:15.909> usually<00:06:16.749> paying<00:06:16.990> you<00:06:17.499> know<00:06:17.589> three 00:06:17.820 --> 00:06:17.830 align:start position:0% merchant usually paying you know three 00:06:17.830 --> 00:06:19.409 align:start position:0% merchant usually paying you know three three<00:06:17.860> percent<00:06:18.639> less<00:06:18.819> 30<00:06:19.059> cents<00:06:19.389> per 00:06:19.409 --> 00:06:19.419 align:start position:0% three percent less 30 cents per 00:06:19.419 --> 00:06:22.199 align:start position:0% three percent less 30 cents per transaction<00:06:19.949> so<00:06:20.949> we<00:06:21.069> can<00:06:21.219> do<00:06:21.399> much<00:06:21.879> better<00:06:21.909> on 00:06:22.199 --> 00:06:22.209 align:start position:0% transaction so we can do much better on 00:06:22.209 --> 00:06:26.129 align:start position:0% transaction so we can do much better on the<00:06:22.509> blockchain<00:06:22.749> with<00:06:23.169> micro<00:06:23.499> vanna's<00:06:25.139> cool 00:06:26.129 --> 00:06:26.139 align:start position:0% the blockchain with micro vanna's cool 00:06:26.139 --> 00:06:30.119 align:start position:0% the blockchain with micro vanna's cool so<00:06:26.349> in<00:06:26.469> summary<00:06:26.849> you<00:06:28.439> guys<00:06:29.439> are<00:06:29.589> just<00:06:29.680> opinion 00:06:30.119 --> 00:06:30.129 align:start position:0% so in summary you guys are just opinion 00:06:30.129 --> 00:06:32.249 align:start position:0% so in summary you guys are just opinion you<00:06:30.189> can<00:06:30.309> charge<00:06:30.580> what<00:06:30.759> you<00:06:30.879> want<00:06:31.120> you<00:06:32.080> can 00:06:32.249 --> 00:06:32.259 align:start position:0% you can charge what you want you can 00:06:32.259 --> 00:06:34.709 align:start position:0% you can charge what you want you can adjust<00:06:32.349> today's<00:06:32.770> values<00:06:33.249> to<00:06:33.610> kind<00:06:34.149> of<00:06:34.180> remove 00:06:34.709 --> 00:06:34.719 align:start position:0% adjust today's values to kind of remove 00:06:34.719 --> 00:06:37.290 align:start position:0% adjust today's values to kind of remove any<00:06:34.899> reliance<00:06:35.259> on<00:06:35.620> gas<00:06:36.520> and<00:06:36.849> congestion 00:06:37.290 --> 00:06:37.300 align:start position:0% any reliance on gas and congestion 00:06:37.300 --> 00:06:41.580 align:start position:0% any reliance on gas and congestion network<00:06:38.200> and<00:06:38.430> overtime<00:06:39.430> you<00:06:39.760> earn<00:06:40.590> exactly 00:06:41.580 --> 00:06:41.590 align:start position:0% network and overtime you earn exactly 00:06:41.590 --> 00:06:44.460 align:start position:0% network and overtime you earn exactly kind<00:06:42.010> of<00:06:42.130> what<00:06:42.880> you<00:06:42.970> wanted<00:06:43.270> to<00:06:43.390> earn<00:06:43.570> with<00:06:44.230> the 00:06:44.460 --> 00:06:44.470 align:start position:0% kind of what you wanted to earn with the 00:06:44.470 --> 00:06:47.940 align:start position:0% kind of what you wanted to earn with the high<00:06:44.620> probability<00:06:46.410> one<00:06:47.410> of<00:06:47.530> the<00:06:47.590> interesting 00:06:47.940 --> 00:06:47.950 align:start position:0% high probability one of the interesting 00:06:47.950 --> 00:06:50.370 align:start position:0% high probability one of the interesting mental<00:06:48.250> models<00:06:48.580> that<00:06:48.940> here<00:06:49.660> you're<00:06:49.990> not 00:06:50.370 --> 00:06:50.380 align:start position:0% mental models that here you're not 00:06:50.380 --> 00:06:52.710 align:start position:0% mental models that here you're not guaranteed<00:06:51.100> to<00:06:51.490> get<00:06:51.640> the<00:06:51.790> exact<00:06:52.150> amount<00:06:52.330> of 00:06:52.710 --> 00:06:52.720 align:start position:0% guaranteed to get the exact amount of 00:06:52.720 --> 00:06:54.660 align:start position:0% guaranteed to get the exact amount of payment<00:06:53.110> for<00:06:53.260> the<00:06:53.350> service<00:06:53.620> you<00:06:53.650> provided<00:06:54.070> but 00:06:54.660 --> 00:06:54.670 align:start position:0% payment for the service you provided but 00:06:54.670 --> 00:06:57.180 align:start position:0% payment for the service you provided but over<00:06:55.030> a<00:06:55.060> long<00:06:55.510> period<00:06:55.840> of<00:06:55.900> time<00:06:55.960> due<00:06:56.890> to<00:06:56.920> kind 00:06:57.180 --> 00:06:57.190 align:start position:0% over a long period of time due to kind 00:06:57.190 --> 00:06:58.200 align:start position:0% over a long period of time due to kind of<00:06:57.250> a<00:06:57.280> lot<00:06:57.430> of<00:06:57.490> large<00:06:57.700> numbers<00:06:58.030> and 00:06:58.200 --> 00:06:58.210 align:start position:0% of a lot of large numbers and 00:06:58.210 --> 00:06:59.880 align:start position:0% of a lot of large numbers and probabilities<00:06:58.750> the<00:06:59.230> amount<00:06:59.410> you<00:06:59.530> earn<00:06:59.650> the 00:06:59.880 --> 00:06:59.890 align:start position:0% probabilities the amount you earn the 00:06:59.890 --> 00:07:03.450 align:start position:0% probabilities the amount you earn the amount<00:07:00.100> you<00:07:00.190> pay<00:07:00.220> will<00:07:01.030> be<00:07:01.240> very<00:07:02.110> close<00:07:02.470> to<00:07:02.890> you 00:07:03.450 --> 00:07:03.460 align:start position:0% amount you pay will be very close to you 00:07:03.460 --> 00:07:05.610 align:start position:0% amount you pay will be very close to you know<00:07:03.520> what<00:07:03.700> was<00:07:03.820> intended<00:07:04.260> so<00:07:05.260> that's<00:07:05.440> the 00:07:05.610 --> 00:07:05.620 align:start position:0% know what was intended so that's the 00:07:05.620 --> 00:07:08.850 align:start position:0% know what was intended so that's the that's<00:07:06.160> the<00:07:06.280> model<00:07:06.490> so<00:07:07.140> brief<00:07:08.140> acknowledgment 00:07:08.850 --> 00:07:08.860 align:start position:0% that's the model so brief acknowledgment 00:07:08.860 --> 00:07:10.350 align:start position:0% that's the model so brief acknowledgment to<00:07:08.980> this<00:07:09.070> is<00:07:09.250> not<00:07:09.400> something<00:07:09.760> we<00:07:09.850> invented<00:07:09.970> it 00:07:10.350 --> 00:07:10.360 align:start position:0% to this is not something we invented it 00:07:10.360 --> 00:07:13.170 align:start position:0% to this is not something we invented it by<00:07:10.510> Pierre<00:07:10.900> Ron<00:07:11.680> Rivest<00:07:12.070> of<00:07:12.370> RSA<00:07:12.880> Fame 00:07:13.170 --> 00:07:13.180 align:start position:0% by Pierre Ron Rivest of RSA Fame 00:07:13.180 --> 00:07:16.070 align:start position:0% by Pierre Ron Rivest of RSA Fame actually<00:07:13.720> proposed<00:07:14.110> this<00:07:14.320> back<00:07:14.800> in<00:07:14.920> 1996 00:07:16.070 --> 00:07:16.080 align:start position:0% actually proposed this back in 1996 00:07:16.080 --> 00:07:18.000 align:start position:0% actually proposed this back in 1996 number<00:07:17.080> of<00:07:17.170> people<00:07:17.380> have<00:07:17.470> proposed<00:07:17.770> it<00:07:17.920> at 00:07:18.000 --> 00:07:18.010 align:start position:0% number of people have proposed it at 00:07:18.010 --> 00:07:20.220 align:start position:0% number of people have proposed it at Bitcoin<00:07:18.220> the<00:07:19.030> orchid<00:07:19.330> protocol<00:07:19.810> proposed 00:07:20.220 --> 00:07:20.230 align:start position:0% Bitcoin the orchid protocol proposed 00:07:20.230 --> 00:07:24.060 align:start position:0% Bitcoin the orchid protocol proposed this<00:07:20.380> a<00:07:20.440> couple<00:07:20.770> years<00:07:21.070> on<00:07:21.550> etherium<00:07:22.330> I<00:07:23.290> think 00:07:24.060 --> 00:07:24.070 align:start position:0% this a couple years on etherium I think 00:07:24.070 --> 00:07:25.770 align:start position:0% this a couple years on etherium I think we've<00:07:24.190> done<00:07:24.340> the<00:07:24.400> first<00:07:24.730> open<00:07:25.600> source 00:07:25.770 --> 00:07:25.780 align:start position:0% we've done the first open source 00:07:25.780 --> 00:07:27.060 align:start position:0% we've done the first open source implementation<00:07:26.440> that<00:07:26.650> people<00:07:26.890> could<00:07:27.040> use 00:07:27.060 --> 00:07:27.070 align:start position:0% implementation that people could use 00:07:27.070 --> 00:07:31.110 align:start position:0% implementation that people could use that's<00:07:28.000> running<00:07:28.240> today<00:07:28.450> but<00:07:29.850> you<00:07:30.850> know<00:07:31.000> this 00:07:31.110 --> 00:07:31.120 align:start position:0% that's running today but you know this 00:07:31.120 --> 00:07:33.270 align:start position:0% that's running today but you know this is<00:07:31.240> a<00:07:31.530> idea<00:07:32.530> that's<00:07:32.680> been<00:07:32.770> around<00:07:32.830> for<00:07:33.220> a<00:07:33.250> while 00:07:33.270 --> 00:07:33.280 align:start position:0% is a idea that's been around for a while 00:07:33.280 --> 00:07:35.490 align:start position:0% is a idea that's been around for a while as<00:07:33.460> peruse<00:07:33.910> there<00:07:34.090> so<00:07:34.720> it's<00:07:34.990> worth<00:07:35.140> asking<00:07:35.260> the 00:07:35.490 --> 00:07:35.500 align:start position:0% as peruse there so it's worth asking the 00:07:35.500 --> 00:07:38.250 align:start position:0% as peruse there so it's worth asking the question<00:07:35.920> now<00:07:36.070> rpm<00:07:37.030> is<00:07:37.090> a<00:07:37.150> good<00:07:37.420> solution<00:07:37.660> for 00:07:38.250 --> 00:07:38.260 align:start position:0% question now rpm is a good solution for 00:07:38.260 --> 00:07:40.590 align:start position:0% question now rpm is a good solution for micro<00:07:38.920> payments<00:07:39.400> until<00:07:39.850> everyone<00:07:40.210> looking<00:07:40.510> at 00:07:40.590 --> 00:07:40.600 align:start position:0% micro payments until everyone looking at 00:07:40.600 --> 00:07:41.730 align:start position:0% micro payments until everyone looking at what<00:07:40.720> are<00:07:40.810> the<00:07:40.900> requirements<00:07:41.260> for<00:07:41.530> good 00:07:41.730 --> 00:07:41.740 align:start position:0% what are the requirements for good 00:07:41.740 --> 00:07:44.580 align:start position:0% what are the requirements for good payment<00:07:41.920> solution<00:07:42.580> so<00:07:43.330> first<00:07:44.260> of<00:07:44.350> all<00:07:44.410> they're 00:07:44.580 --> 00:07:44.590 align:start position:0% payment solution so first of all they're 00:07:44.590 --> 00:07:47.580 align:start position:0% payment solution so first of all they're low<00:07:44.770> latency<00:07:45.310> you<00:07:45.520> can<00:07:45.730> send<00:07:46.110> these<00:07:47.110> payments 00:07:47.580 --> 00:07:47.590 align:start position:0% low latency you can send these payments 00:07:47.590 --> 00:07:49.200 align:start position:0% low latency you can send these payments around<00:07:47.680> very<00:07:47.980> quickly<00:07:48.250> it's<00:07:48.520> all<00:07:48.610> a<00:07:48.670> chain<00:07:49.090> you 00:07:49.200 --> 00:07:49.210 align:start position:0% around very quickly it's all a chain you 00:07:49.210 --> 00:07:50.970 align:start position:0% around very quickly it's all a chain you never<00:07:49.390> need<00:07:49.630> to<00:07:49.810> go<00:07:49.960> to<00:07:50.020> the<00:07:50.170> blockchain<00:07:50.410> to 00:07:50.970 --> 00:07:50.980 align:start position:0% never need to go to the blockchain to 00:07:50.980 --> 00:07:53.160 align:start position:0% never need to go to the blockchain to check<00:07:51.220> if<00:07:51.400> but<00:07:52.030> you<00:07:52.180> need<00:07:52.450> to<00:07:52.600> submit<00:07:53.080> a 00:07:53.160 --> 00:07:53.170 align:start position:0% check if but you need to submit a 00:07:53.170 --> 00:07:54.810 align:start position:0% check if but you need to submit a transaction<00:07:53.770> to<00:07:53.800> the<00:07:54.010> blockchain<00:07:54.220> in<00:07:54.640> order 00:07:54.810 --> 00:07:54.820 align:start position:0% transaction to the blockchain in order 00:07:54.820 --> 00:07:57.930 align:start position:0% transaction to the blockchain in order to<00:07:54.940> pay<00:07:55.090> someone<00:07:56.160> it<00:07:57.160> allows<00:07:57.400> you<00:07:57.550> to<00:07:57.610> switch 00:07:57.930 --> 00:07:57.940 align:start position:0% to pay someone it allows you to switch 00:07:57.940 --> 00:08:01.320 align:start position:0% to pay someone it allows you to switch recipients<00:07:58.690> seamlessly<00:07:59.230> so<00:07:59.290> you<00:07:59.650> can<00:08:00.240> send<00:08:01.240> a 00:08:01.320 --> 00:08:01.330 align:start position:0% recipients seamlessly so you can send a 00:08:01.330 --> 00:08:04.950 align:start position:0% recipients seamlessly so you can send a payment<00:08:01.690> to<00:08:02.280> multiple<00:08:03.280> providers<00:08:03.840> one<00:08:04.840> at<00:08:04.930> a 00:08:04.950 --> 00:08:04.960 align:start position:0% payment to multiple providers one at a 00:08:04.960 --> 00:08:08.400 align:start position:0% payment to multiple providers one at a time<00:08:05.200> or<00:08:05.790> pay<00:08:06.790> them<00:08:06.970> simultaneously<00:08:07.870> all<00:08:08.230> at 00:08:08.400 --> 00:08:08.410 align:start position:0% time or pay them simultaneously all at 00:08:08.410 --> 00:08:12.990 align:start position:0% time or pay them simultaneously all at the<00:08:08.470> same<00:08:08.650> time<00:08:09.450> you<00:08:11.070> don't<00:08:12.070> need<00:08:12.430> to<00:08:12.640> go<00:08:12.790> on<00:08:12.970> a 00:08:12.990 --> 00:08:13.000 align:start position:0% the same time you don't need to go on a 00:08:13.000 --> 00:08:15.030 align:start position:0% the same time you don't need to go on a chain<00:08:13.330> to<00:08:13.540> add<00:08:13.660> a<00:08:13.690> new<00:08:13.900> recipient<00:08:14.500> so<00:08:14.650> for 00:08:15.030 --> 00:08:15.040 align:start position:0% chain to add a new recipient so for 00:08:15.040 --> 00:08:17.580 align:start position:0% chain to add a new recipient so for example<00:08:15.370> in<00:08:15.490> my<00:08:15.610> dear<00:08:16.020> you're<00:08:17.020> encoding<00:08:17.470> video 00:08:17.580 --> 00:08:17.590 align:start position:0% example in my dear you're encoding video 00:08:17.590 --> 00:08:18.670 align:start position:0% example in my dear you're encoding video on<00:08:17.860> this<00:08:18.010> network<00:08:18.190> and 00:08:18.670 --> 00:08:18.680 align:start position:0% on this network and 00:08:18.680 --> 00:08:20.230 align:start position:0% on this network and hundreds<00:08:19.039> or<00:08:19.160> thousands<00:08:19.550> of<00:08:19.639> people<00:08:19.699> who<00:08:20.090> can 00:08:20.230 --> 00:08:20.240 align:start position:0% hundreds or thousands of people who can 00:08:20.240 --> 00:08:22.029 align:start position:0% hundreds or thousands of people who can enter<00:08:20.389> a<00:08:20.570> video<00:08:20.840> for<00:08:21.139> you<00:08:21.289> you<00:08:21.740> don't<00:08:21.830> need<00:08:21.979> to 00:08:22.029 --> 00:08:22.039 align:start position:0% enter a video for you you don't need to 00:08:22.039 --> 00:08:23.770 align:start position:0% enter a video for you you don't need to go<00:08:22.310> on<00:08:22.340> into<00:08:22.639> the<00:08:22.729> blockchain<00:08:22.940> to<00:08:23.360> open<00:08:23.690> a 00:08:23.770 --> 00:08:23.780 align:start position:0% go on into the blockchain to open a 00:08:23.780 --> 00:08:25.480 align:start position:0% go on into the blockchain to open a channel<00:08:24.169> with<00:08:24.350> each<00:08:24.500> of<00:08:24.650> them<00:08:24.860> you<00:08:25.310> can<00:08:25.460> just 00:08:25.480 --> 00:08:25.490 align:start position:0% channel with each of them you can just 00:08:25.490 --> 00:08:28.779 align:start position:0% channel with each of them you can just start<00:08:25.789> sending<00:08:26.710> payments<00:08:27.710> to<00:08:28.370> them<00:08:28.520> as<00:08:28.699> they 00:08:28.779 --> 00:08:28.789 align:start position:0% start sending payments to them as they 00:08:28.789 --> 00:08:31.689 align:start position:0% start sending payments to them as they come<00:08:28.940> available<00:08:29.440> and<00:08:30.440> finally<00:08:31.190> this<00:08:31.460> one's 00:08:31.689 --> 00:08:31.699 align:start position:0% come available and finally this one's 00:08:31.699 --> 00:08:33.940 align:start position:0% come available and finally this one's also<00:08:32.029> really<00:08:32.270> important<00:08:32.800> there's<00:08:33.800> no 00:08:33.940 --> 00:08:33.950 align:start position:0% also really important there's no 00:08:33.950 --> 00:08:35.680 align:start position:0% also really important there's no expectation<00:08:34.760> that<00:08:34.789> you<00:08:35.089> have<00:08:35.209> to<00:08:35.300> have<00:08:35.419> a<00:08:35.479> long 00:08:35.680 --> 00:08:35.690 align:start position:0% expectation that you have to have a long 00:08:35.690 --> 00:08:37.959 align:start position:0% expectation that you have to have a long lived<00:08:36.050> relationship<00:08:36.740> with<00:08:37.070> the<00:08:37.190> recipient<00:08:37.760> or 00:08:37.959 --> 00:08:37.969 align:start position:0% lived relationship with the recipient or 00:08:37.969 --> 00:08:40.000 align:start position:0% lived relationship with the recipient or that<00:08:38.659> you<00:08:38.719> have<00:08:38.839> to<00:08:38.990> sometime<00:08:39.260> a<00:08:39.320> live<00:08:39.529> value 00:08:40.000 --> 00:08:40.010 align:start position:0% that you have to sometime a live value 00:08:40.010 --> 00:08:41.769 align:start position:0% that you have to sometime a live value for<00:08:40.190> it<00:08:40.279> to<00:08:40.370> be<00:08:40.459> worth<00:08:40.669> it 00:08:41.769 --> 00:08:41.779 align:start position:0% for it to be worth it 00:08:41.779 --> 00:08:43.899 align:start position:0% for it to be worth it in<00:08:42.169> payment<00:08:42.770> channels<00:08:43.039> for<00:08:43.159> example<00:08:43.250> if<00:08:43.760> you 00:08:43.899 --> 00:08:43.909 align:start position:0% in payment channels for example if you 00:08:43.909 --> 00:08:46.840 align:start position:0% in payment channels for example if you never<00:08:44.120> closed<00:08:44.480> a<00:08:44.510> channel<00:08:45.080> with<00:08:45.260> one<00:08:45.500> user<00:08:45.850> if 00:08:46.840 --> 00:08:46.850 align:start position:0% never closed a channel with one user if 00:08:46.850 --> 00:08:48.220 align:start position:0% never closed a channel with one user if you<00:08:47.089> were<00:08:47.209> only<00:08:47.360> going<00:08:47.570> to<00:08:47.630> be<00:08:47.720> cashing<00:08:47.959> out 00:08:48.220 --> 00:08:48.230 align:start position:0% you were only going to be cashing out 00:08:48.230 --> 00:08:49.480 align:start position:0% you were only going to be cashing out you<00:08:49.070> know 00:08:49.480 --> 00:08:49.490 align:start position:0% you know 00:08:49.490 --> 00:08:52.139 align:start position:0% you know five<00:08:49.940> cents<00:08:50.360> worth<00:08:50.510> of<00:08:50.690> value<00:08:51.410> because<00:08:51.770> the 00:08:52.139 --> 00:08:52.149 align:start position:0% five cents worth of value because the 00:08:52.149 --> 00:08:54.639 align:start position:0% five cents worth of value because the transaction<00:08:53.149> cost<00:08:53.360> would<00:08:53.480> be<00:08:53.540> too<00:08:53.750> high<00:08:53.959> where 00:08:54.639 --> 00:08:54.649 align:start position:0% transaction cost would be too high where 00:08:54.649 --> 00:08:56.500 align:start position:0% transaction cost would be too high where is<00:08:54.830> it<00:08:54.980> micro<00:08:55.220> payments<00:08:55.610> you<00:08:56.000> don't<00:08:56.149> have<00:08:56.330> to 00:08:56.500 --> 00:08:56.510 align:start position:0% is it micro payments you don't have to 00:08:56.510 --> 00:08:58.060 align:start position:0% is it micro payments you don't have to assume<00:08:56.839> that<00:08:57.050> you're<00:08:57.200> going<00:08:57.350> to<00:08:57.410> be<00:08:57.529> earning 00:08:58.060 --> 00:08:58.070 align:start position:0% assume that you're going to be earning 00:08:58.070 --> 00:09:00.610 align:start position:0% assume that you're going to be earning five<00:08:58.459> cents<00:08:58.700> 10<00:08:58.880> cents<00:08:59.120> a<00:08:59.240> dollar<00:08:59.620> hundred 00:09:00.610 --> 00:09:00.620 align:start position:0% five cents 10 cents a dollar hundred 00:09:00.620 --> 00:09:02.740 align:start position:0% five cents 10 cents a dollar hundred dollars<00:09:00.860> a<00:09:00.890> thousand<00:09:01.279> dollars<00:09:01.610> you<00:09:02.420> can<00:09:02.570> just 00:09:02.740 --> 00:09:02.750 align:start position:0% dollars a thousand dollars you can just 00:09:02.750 --> 00:09:04.690 align:start position:0% dollars a thousand dollars you can just you<00:09:03.230> know<00:09:03.260> the<00:09:03.470> expected<00:09:03.800> value<00:09:04.250> of<00:09:04.279> a<00:09:04.370> ticket 00:09:04.690 --> 00:09:04.700 align:start position:0% you know the expected value of a ticket 00:09:04.700 --> 00:09:06.610 align:start position:0% you know the expected value of a ticket if<00:09:04.850> it<00:09:04.970> wins<00:09:05.149> it's<00:09:05.390> always<00:09:05.660> worth<00:09:05.930> whatever 00:09:06.610 --> 00:09:06.620 align:start position:0% if it wins it's always worth whatever 00:09:06.620 --> 00:09:08.769 align:start position:0% if it wins it's always worth whatever face<00:09:06.950> value<00:09:07.310> you<00:09:07.339> moderate<00:09:07.850> it<00:09:07.970> to<00:09:08.089> be<00:09:08.270> to<00:09:08.660> make 00:09:08.769 --> 00:09:08.779 align:start position:0% face value you moderate it to be to make 00:09:08.779 --> 00:09:10.019 align:start position:0% face value you moderate it to be to make it<00:09:08.930> worth<00:09:09.050> your<00:09:09.080> while 00:09:10.019 --> 00:09:10.029 align:start position:0% it worth your while 00:09:10.029 --> 00:09:13.440 align:start position:0% it worth your while so<00:09:11.029> those<00:09:11.660> really<00:09:11.959> nice<00:09:12.080> property<00:09:12.560> so 00:09:13.440 --> 00:09:13.450 align:start position:0% so those really nice property so 00:09:13.450 --> 00:09:16.900 align:start position:0% so those really nice property so probabilistic<00:09:14.450> micro<00:09:14.930> payments<00:09:15.350> support<00:09:15.910> all 00:09:16.900 --> 00:09:16.910 align:start position:0% probabilistic micro payments support all 00:09:16.910 --> 00:09:19.389 align:start position:0% probabilistic micro payments support all of<00:09:17.209> these<00:09:17.390> properties<00:09:18.320> which<00:09:19.040> makes<00:09:19.310> a<00:09:19.339> really 00:09:19.389 --> 00:09:19.399 align:start position:0% of these properties which makes a really 00:09:19.399 --> 00:09:22.630 align:start position:0% of these properties which makes a really nice<00:09:19.700> food<00:09:19.970> for<00:09:20.390> streaming<00:09:20.870> data<00:09:21.110> use<00:09:21.380> cases 00:09:22.630 --> 00:09:22.640 align:start position:0% nice food for streaming data use cases 00:09:22.640 --> 00:09:24.310 align:start position:0% nice food for streaming data use cases next<00:09:23.300> up<00:09:23.450> what<00:09:23.630> I<00:09:23.660> want<00:09:23.839> I<00:09:23.870> just<00:09:24.020> have<00:09:24.140> already 00:09:24.310 --> 00:09:24.320 align:start position:0% next up what I want I just have already 00:09:24.320 --> 00:09:26.590 align:start position:0% next up what I want I just have already on<00:09:24.620> did<00:09:24.830> so<00:09:24.980> you<00:09:25.070> can<00:09:25.160> compare<00:09:25.610> probabilistic 00:09:26.590 --> 00:09:26.600 align:start position:0% on did so you can compare probabilistic 00:09:26.600 --> 00:09:28.780 align:start position:0% on did so you can compare probabilistic micropayments<00:09:27.260> to<00:09:27.650> traditional<00:09:28.100> payment 00:09:28.780 --> 00:09:28.790 align:start position:0% micropayments to traditional payment 00:09:28.790 --> 00:09:29.980 align:start position:0% micropayments to traditional payment channels<00:09:29.120> like<00:09:29.480> we've<00:09:29.600> heard<00:09:29.750> a<00:09:29.810> lot<00:09:29.959> about 00:09:29.980 --> 00:09:29.990 align:start position:0% channels like we've heard a lot about 00:09:29.990 --> 00:09:36.190 align:start position:0% channels like we've heard a lot about this<00:09:30.350> conference<00:09:30.620> this<00:09:30.830> week<00:09:34.900> alright<00:09:35.900> so 00:09:36.190 --> 00:09:36.200 align:start position:0% this conference this week alright so 00:09:36.200 --> 00:09:38.050 align:start position:0% this conference this week alright so before<00:09:36.470> we<00:09:36.770> talk<00:09:36.950> a<00:09:37.010> little<00:09:37.190> bit<00:09:37.430> more<00:09:37.459> about 00:09:38.050 --> 00:09:38.060 align:start position:0% before we talk a little bit more about 00:09:38.060 --> 00:09:40.960 align:start position:0% before we talk a little bit more about the<00:09:38.660> security<00:09:39.529> model<00:09:39.680> for<00:09:40.100> all<00:09:40.610> the<00:09:40.760> state 00:09:40.960 --> 00:09:40.970 align:start position:0% the security model for all the state 00:09:40.970 --> 00:09:42.430 align:start position:0% the security model for all the state micropayments<00:09:41.330> is<00:09:41.660> where<00:09:41.839> it's<00:09:41.990> doing<00:09:42.260> a 00:09:42.430 --> 00:09:42.440 align:start position:0% micropayments is where it's doing a 00:09:42.440 --> 00:09:44.530 align:start position:0% micropayments is where it's doing a comparison<00:09:43.250> with<00:09:43.490> some<00:09:43.820> common 00:09:44.530 --> 00:09:44.540 align:start position:0% comparison with some common 00:09:44.540 --> 00:09:46.510 align:start position:0% comparison with some common constructions<00:09:45.080> that<00:09:45.290> are<00:09:45.680> used<00:09:45.980> in<00:09:46.279> the 00:09:46.510 --> 00:09:46.520 align:start position:0% constructions that are used in the 00:09:46.520 --> 00:09:49.720 align:start position:0% constructions that are used in the national<00:09:47.150> space<00:09:47.360> so<00:09:48.160> before<00:09:49.160> in<00:09:49.310> order<00:09:49.459> to<00:09:49.610> do 00:09:49.720 --> 00:09:49.730 align:start position:0% national space so before in order to do 00:09:49.730 --> 00:09:51.130 align:start position:0% national space so before in order to do this<00:09:49.850> comparison<00:09:50.240> you<00:09:50.570> actually<00:09:50.870> need<00:09:51.050> to 00:09:51.130 --> 00:09:51.140 align:start position:0% this comparison you actually need to 00:09:51.140 --> 00:09:53.620 align:start position:0% this comparison you actually need to highlight<00:09:51.550> specific<00:09:52.550> characteristics<00:09:53.450> of 00:09:53.620 --> 00:09:53.630 align:start position:0% highlight specific characteristics of 00:09:53.630 --> 00:09:55.570 align:start position:0% highlight specific characteristics of their<00:09:53.779> character<00:09:54.160> construction<00:09:55.160> so<00:09:55.400> there's 00:09:55.570 --> 00:09:55.580 align:start position:0% their character construction so there's 00:09:55.580 --> 00:09:56.190 align:start position:0% their character construction so there's different<00:09:55.700> types 00:09:56.190 --> 00:09:56.200 align:start position:0% different types 00:09:56.200 --> 00:09:58.010 align:start position:0% different types Peyman<00:09:56.500> channel<00:09:56.770> instructions<00:09:57.340> ranging<00:09:57.760> from 00:09:58.010 --> 00:09:58.020 align:start position:0% Peyman channel instructions ranging from 00:09:58.020 --> 00:10:00.870 align:start position:0% Peyman channel instructions ranging from individual<00:09:59.020> vanilla<00:09:59.410> channels<00:09:59.890> to<00:10:00.220> more 00:10:00.870 --> 00:10:00.880 align:start position:0% individual vanilla channels to more 00:10:00.880 --> 00:10:03.270 align:start position:0% individual vanilla channels to more complex<00:10:01.240> network<00:10:01.660> channels<00:10:02.050> that<00:10:02.260> solve<00:10:03.040> some 00:10:03.270 --> 00:10:03.280 align:start position:0% complex network channels that solve some 00:10:03.280 --> 00:10:04.500 align:start position:0% complex network channels that solve some of<00:10:03.310> the<00:10:03.430> problems<00:10:03.820> that<00:10:03.970> are<00:10:04.060> present<00:10:04.390> in 00:10:04.500 --> 00:10:04.510 align:start position:0% of the problems that are present in 00:10:04.510 --> 00:10:06.210 align:start position:0% of the problems that are present in individual<00:10:05.080> channels<00:10:05.440> and<00:10:05.710> then<00:10:05.800> even<00:10:06.070> within 00:10:06.210 --> 00:10:06.220 align:start position:0% individual channels and then even within 00:10:06.220 --> 00:10:08.460 align:start position:0% individual channels and then even within that<00:10:06.370> category<00:10:06.730> you<00:10:07.660> have<00:10:07.870> different<00:10:08.290> types 00:10:08.460 --> 00:10:08.470 align:start position:0% that category you have different types 00:10:08.470 --> 00:10:10.260 align:start position:0% that category you have different types of<00:10:08.590> routing<00:10:08.770> you<00:10:09.070> have<00:10:09.190> h<00:10:09.370> TLC<00:10:09.850> based<00:10:10.090> routing 00:10:10.260 --> 00:10:10.270 align:start position:0% of routing you have h TLC based routing 00:10:10.270 --> 00:10:12.240 align:start position:0% of routing you have h TLC based routing and<00:10:10.660> you<00:10:10.810> also<00:10:10.960> have<00:10:11.290> virtual<00:10:11.710> channel<00:10:12.070> based 00:10:12.240 --> 00:10:12.250 align:start position:0% and you also have virtual channel based 00:10:12.250 --> 00:10:14.430 align:start position:0% and you also have virtual channel based routing<00:10:12.430> and<00:10:12.850> on<00:10:13.450> top<00:10:13.660> of<00:10:13.690> that<00:10:13.810> you<00:10:14.140> can<00:10:14.290> also 00:10:14.430 --> 00:10:14.440 align:start position:0% routing and on top of that you can also 00:10:14.440 --> 00:10:16.050 align:start position:0% routing and on top of that you can also distinguish<00:10:15.010> between<00:10:15.160> different<00:10:15.670> types<00:10:15.760> of 00:10:16.050 --> 00:10:16.060 align:start position:0% distinguish between different types of 00:10:16.060 --> 00:10:18.120 align:start position:0% distinguish between different types of network<00:10:16.510> topology<00:10:16.660> so<00:10:17.620> you<00:10:17.710> might<00:10:17.890> have<00:10:18.100> a 00:10:18.120 --> 00:10:18.130 align:start position:0% network topology so you might have a 00:10:18.130 --> 00:10:20.490 align:start position:0% network topology so you might have a multi<00:10:18.610> hot<00:10:18.760> type<00:10:19.030> network<00:10:19.390> or<00:10:19.780> you<00:10:20.140> might<00:10:20.290> have 00:10:20.490 --> 00:10:20.500 align:start position:0% multi hot type network or you might have 00:10:20.500 --> 00:10:23.130 align:start position:0% multi hot type network or you might have a<00:10:20.530> hub-and-spoke<00:10:20.830> type<00:10:21.340> network<00:10:21.930> the<00:10:22.930> full 00:10:23.130 --> 00:10:23.140 align:start position:0% a hub-and-spoke type network the full 00:10:23.140 --> 00:10:25.050 align:start position:0% a hub-and-spoke type network the full details<00:10:23.530> of<00:10:23.860> these<00:10:24.190> types<00:10:24.430> of<00:10:24.520> constructions 00:10:25.050 --> 00:10:25.060 align:start position:0% details of these types of constructions 00:10:25.060 --> 00:10:26.130 align:start position:0% details of these types of constructions are<00:10:25.240> kind<00:10:25.390> of<00:10:25.420> out<00:10:25.540> of<00:10:25.570> the<00:10:25.660> scope<00:10:25.900> of<00:10:26.050> this 00:10:26.130 --> 00:10:26.140 align:start position:0% are kind of out of the scope of this 00:10:26.140 --> 00:10:27.630 align:start position:0% are kind of out of the scope of this presentation<00:10:26.320> but<00:10:27.010> there's<00:10:27.280> a<00:10:27.310> lot<00:10:27.430> of<00:10:27.520> good 00:10:27.630 --> 00:10:27.640 align:start position:0% presentation but there's a lot of good 00:10:27.640 --> 00:10:29.520 align:start position:0% presentation but there's a lot of good presentations<00:10:28.240> at<00:10:28.390> this<00:10:28.510> conference<00:10:28.750> that<00:10:29.290> go 00:10:29.520 --> 00:10:29.530 align:start position:0% presentations at this conference that go 00:10:29.530 --> 00:10:33.450 align:start position:0% presentations at this conference that go into<00:10:29.680> more<00:10:29.890> detail<00:10:30.720> so<00:10:31.720> for<00:10:32.290> the<00:10:32.890> comparison 00:10:33.450 --> 00:10:33.460 align:start position:0% into more detail so for the comparison 00:10:33.460 --> 00:10:35.340 align:start position:0% into more detail so for the comparison for<00:10:33.610> individual<00:10:34.090> image<00:10:34.450> channels<00:10:34.780> we<00:10:34.960> can<00:10:35.140> see 00:10:35.340 --> 00:10:35.350 align:start position:0% for individual image channels we can see 00:10:35.350 --> 00:10:37.980 align:start position:0% for individual image channels we can see that<00:10:35.680> the<00:10:36.100> two<00:10:36.310> main<00:10:36.520> cons<00:10:36.790> of<00:10:37.180> using<00:10:37.630> just 00:10:37.980 --> 00:10:37.990 align:start position:0% that the two main cons of using just 00:10:37.990 --> 00:10:40.290 align:start position:0% that the two main cons of using just vanilla<00:10:38.230> payment<00:10:38.740> channels<00:10:39.040> are<00:10:39.370> around 00:10:40.290 --> 00:10:40.300 align:start position:0% vanilla payment channels are around 00:10:40.300 --> 00:10:42.390 align:start position:0% vanilla payment channels are around additional<00:10:40.930> launching<00:10:41.260> setup<00:10:41.590> involved<00:10:41.980> with 00:10:42.390 --> 00:10:42.400 align:start position:0% additional launching setup involved with 00:10:42.400 --> 00:10:44.040 align:start position:0% additional launching setup involved with each<00:10:42.760> counterparty<00:10:43.420> that<00:10:43.600> you<00:10:43.690> want<00:10:43.870> to<00:10:43.930> work 00:10:44.040 --> 00:10:44.050 align:start position:0% each counterparty that you want to work 00:10:44.050 --> 00:10:46.050 align:start position:0% each counterparty that you want to work with<00:10:44.260> so<00:10:44.590> in<00:10:44.770> a<00:10:44.830> network<00:10:45.130> where<00:10:45.370> you<00:10:45.640> might 00:10:46.050 --> 00:10:46.060 align:start position:0% with so in a network where you might 00:10:46.060 --> 00:10:47.880 align:start position:0% with so in a network where you might have<00:10:46.090> open<00:10:46.600> entry<00:10:47.080> and<00:10:47.200> exit<00:10:47.500> into<00:10:47.680> the 00:10:47.880 --> 00:10:47.890 align:start position:0% have open entry and exit into the 00:10:47.890 --> 00:10:49.740 align:start position:0% have open entry and exit into the recipient<00:10:48.130> set<00:10:48.550> you<00:10:49.120> would<00:10:49.210> prefer<00:10:49.360> not<00:10:49.720> to 00:10:49.740 --> 00:10:49.750 align:start position:0% recipient set you would prefer not to 00:10:49.750 --> 00:10:51.900 align:start position:0% recipient set you would prefer not to have<00:10:50.020> to<00:10:50.080> incur<00:10:50.530> an<00:10:50.920> on<00:10:51.070> change<00:10:51.310> setup<00:10:51.640> cost 00:10:51.900 --> 00:10:51.910 align:start position:0% have to incur an on change setup cost 00:10:51.910 --> 00:10:54.020 align:start position:0% have to incur an on change setup cost that<00:10:52.180> rises<00:10:52.570> linearly<00:10:52.900> with<00:10:53.170> the<00:10:53.320> number<00:10:53.440> of 00:10:54.020 --> 00:10:54.030 align:start position:0% that rises linearly with the number of 00:10:54.030 --> 00:10:57.170 align:start position:0% that rises linearly with the number of new<00:10:55.030> recipients<00:10:55.690> packages<00:10:56.230> of<00:10:56.410> this<00:10:56.530> set<00:10:56.710> and 00:10:57.170 --> 00:10:57.180 align:start position:0% new recipients packages of this set and 00:10:57.180 --> 00:10:59.730 align:start position:0% new recipients packages of this set and as<00:10:58.180> it's<00:10:58.600> mentioned<00:10:58.750> previously<00:10:59.350> there<00:10:59.620> is 00:10:59.730 --> 00:10:59.740 align:start position:0% as it's mentioned previously there is 00:10:59.740 --> 00:11:02.160 align:start position:0% as it's mentioned previously there is the<00:10:59.860> possibility<00:11:00.250> of<00:11:00.490> dust<00:11:01.180> being<00:11:01.600> in<00:11:01.900> your 00:11:02.160 --> 00:11:02.170 align:start position:0% the possibility of dust being in your 00:11:02.170 --> 00:11:04.050 align:start position:0% the possibility of dust being in your channel<00:11:02.470> balance<00:11:02.680> so<00:11:03.220> if<00:11:03.490> you<00:11:03.580> have<00:11:03.700> a<00:11:03.730> small 00:11:04.050 --> 00:11:04.060 align:start position:0% channel balance so if you have a small 00:11:04.060 --> 00:11:06.210 align:start position:0% channel balance so if you have a small amount<00:11:04.750> in<00:11:04.960> your<00:11:05.080> channel<00:11:05.320> such<00:11:05.710> that<00:11:05.920> it<00:11:06.130> is 00:11:06.210 --> 00:11:06.220 align:start position:0% amount in your channel such that it is 00:11:06.220 --> 00:11:08.490 align:start position:0% amount in your channel such that it is considered<00:11:06.580> dust<00:11:06.940> and<00:11:07.270> the<00:11:08.110> launching 00:11:08.490 --> 00:11:08.500 align:start position:0% considered dust and the launching 00:11:08.500 --> 00:11:10.410 align:start position:0% considered dust and the launching transaction<00:11:09.040> cost<00:11:09.250> is<00:11:09.460> going<00:11:09.700> to<00:11:09.850> exceed<00:11:10.180> the 00:11:10.410 --> 00:11:10.420 align:start position:0% transaction cost is going to exceed the 00:11:10.420 --> 00:11:12.120 align:start position:0% transaction cost is going to exceed the cost<00:11:10.630> of<00:11:10.900> actually<00:11:11.050> withdrawing<00:11:11.650> that<00:11:11.770> dust 00:11:12.120 --> 00:11:12.130 align:start position:0% cost of actually withdrawing that dust 00:11:12.130 --> 00:11:14.400 align:start position:0% cost of actually withdrawing that dust from<00:11:12.430> that<00:11:12.490> channel<00:11:13.180> and<00:11:13.360> it's<00:11:13.990> not 00:11:14.400 --> 00:11:14.410 align:start position:0% from that channel and it's not 00:11:14.410 --> 00:11:17.069 align:start position:0% from that channel and it's not be<00:11:14.470> worth<00:11:14.649> it<00:11:14.920> so<00:11:15.160> in<00:11:15.370> that<00:11:15.399> case<00:11:16.000> you<00:11:16.720> actually 00:11:17.069 --> 00:11:17.079 align:start position:0% be worth it so in that case you actually 00:11:17.079 --> 00:11:19.079 align:start position:0% be worth it so in that case you actually have<00:11:17.230> some<00:11:17.589> minimum<00:11:18.160> value<00:11:18.519> transacted 00:11:19.079 --> 00:11:19.089 align:start position:0% have some minimum value transacted 00:11:19.089 --> 00:11:20.550 align:start position:0% have some minimum value transacted requirement<00:11:19.690> where<00:11:19.899> it's<00:11:20.079> not<00:11:20.230> worth<00:11:20.410> it 00:11:20.550 --> 00:11:20.560 align:start position:0% requirement where it's not worth it 00:11:20.560 --> 00:11:23.790 align:start position:0% requirement where it's not worth it below<00:11:20.860> that<00:11:21.040> amount<00:11:21.720> so<00:11:22.720> with<00:11:23.199> hdl-c 00:11:23.790 --> 00:11:23.800 align:start position:0% below that amount so with hdl-c 00:11:23.800 --> 00:11:26.100 align:start position:0% below that amount so with hdl-c multi-hop<00:11:24.459> channels<00:11:24.910> this<00:11:25.209> is<00:11:25.269> the<00:11:25.660> paradigm 00:11:26.100 --> 00:11:26.110 align:start position:0% multi-hop channels this is the paradigm 00:11:26.110 --> 00:11:27.780 align:start position:0% multi-hop channels this is the paradigm that<00:11:26.139> you<00:11:26.410> might<00:11:26.560> find<00:11:26.769> in<00:11:27.100> a<00:11:27.220> network<00:11:27.519> like 00:11:27.780 --> 00:11:27.790 align:start position:0% that you might find in a network like 00:11:27.790 --> 00:11:30.569 align:start position:0% that you might find in a network like Bitcoin<00:11:28.269> lightning<00:11:28.660> so<00:11:29.410> here<00:11:30.040> I<00:11:30.279> have<00:11:30.550> a 00:11:30.569 --> 00:11:30.579 align:start position:0% Bitcoin lightning so here I have a 00:11:30.579 --> 00:11:32.879 align:start position:0% Bitcoin lightning so here I have a question<00:11:31.089> mark<00:11:31.209> next<00:11:31.449> to<00:11:31.600> low<00:11:31.779> latency<00:11:32.199> mainly 00:11:32.879 --> 00:11:32.889 align:start position:0% question mark next to low latency mainly 00:11:32.889 --> 00:11:35.100 align:start position:0% question mark next to low latency mainly because<00:11:33.069> in<00:11:33.490> the<00:11:33.519> happy<00:11:34.000> case<00:11:34.180> it<00:11:34.449> definitely 00:11:35.100 --> 00:11:35.110 align:start position:0% because in the happy case it definitely 00:11:35.110 --> 00:11:37.139 align:start position:0% because in the happy case it definitely is<00:11:35.230> low<00:11:35.439> latency<00:11:35.829> if<00:11:36.040> your<00:11:36.430> payment<00:11:36.970> can<00:11:37.120> be 00:11:37.139 --> 00:11:37.149 align:start position:0% is low latency if your payment can be 00:11:37.149 --> 00:11:38.790 align:start position:0% is low latency if your payment can be relayed<00:11:37.480> across<00:11:37.750> multiple<00:11:38.050> intermediaries 00:11:38.790 --> 00:11:38.800 align:start position:0% relayed across multiple intermediaries 00:11:38.800 --> 00:11:40.889 align:start position:0% relayed across multiple intermediaries without<00:11:39.100> any<00:11:39.250> delays<00:11:39.610> but<00:11:40.269> if<00:11:40.540> there's<00:11:40.720> any 00:11:40.889 --> 00:11:40.899 align:start position:0% without any delays but if there's any 00:11:40.899 --> 00:11:43.769 align:start position:0% without any delays but if there's any delay<00:11:41.199> in<00:11:41.470> the<00:11:41.860> revelation<00:11:42.639> of<00:11:42.910> the<00:11:43.149> hash<00:11:43.360> used 00:11:43.769 --> 00:11:43.779 align:start position:0% delay in the revelation of the hash used 00:11:43.779 --> 00:11:45.900 align:start position:0% delay in the revelation of the hash used in<00:11:43.959> the<00:11:44.079> HPLC<00:11:44.379> then<00:11:45.189> there's<00:11:45.519> the<00:11:45.610> potential 00:11:45.900 --> 00:11:45.910 align:start position:0% in the HPLC then there's the potential 00:11:45.910 --> 00:11:47.730 align:start position:0% in the HPLC then there's the potential for<00:11:46.060> that<00:11:46.240> to<00:11:46.329> be<00:11:46.389> slowed<00:11:46.629> down<00:11:46.660> so<00:11:47.350> the<00:11:47.470> longer 00:11:47.730 --> 00:11:47.740 align:start position:0% for that to be slowed down so the longer 00:11:47.740 --> 00:11:50.100 align:start position:0% for that to be slowed down so the longer the<00:11:47.860> path<00:11:48.009> the<00:11:48.430> higher<00:11:48.610> the<00:11:48.759> risk<00:11:48.910> of<00:11:49.149> slowing 00:11:50.100 --> 00:11:50.110 align:start position:0% the path the higher the risk of slowing 00:11:50.110 --> 00:11:53.220 align:start position:0% the path the higher the risk of slowing down<00:11:50.170> the<00:11:50.350> payment<00:11:50.680> flow<00:11:50.829> is<00:11:51.870> in<00:11:52.870> addition<00:11:53.079> to 00:11:53.220 --> 00:11:53.230 align:start position:0% down the payment flow is in addition to 00:11:53.230 --> 00:11:55.889 align:start position:0% down the payment flow is in addition to that<00:11:53.470> we<00:11:53.889> also<00:11:54.069> still<00:11:54.490> have<00:11:54.689> minimum<00:11:55.689> value 00:11:55.889 --> 00:11:55.899 align:start position:0% that we also still have minimum value 00:11:55.899 --> 00:11:58.050 align:start position:0% that we also still have minimum value transacted<00:11:56.379> requirements<00:11:57.069> so<00:11:57.250> if<00:11:57.610> you<00:11:57.819> have 00:11:58.050 --> 00:11:58.060 align:start position:0% transacted requirements so if you have 00:11:58.060 --> 00:12:00.240 align:start position:0% transacted requirements so if you have dust<00:11:58.569> in<00:11:58.839> your<00:11:58.990> channel<00:11:59.199> then<00:11:59.860> you<00:12:00.069> can 00:12:00.240 --> 00:12:00.250 align:start position:0% dust in your channel then you can 00:12:00.250 --> 00:12:02.309 align:start position:0% dust in your channel then you can actually<00:12:00.490> use<00:12:00.819> this<00:12:01.000> hdl-c<00:12:01.449> mechanism<00:12:02.170> in 00:12:02.309 --> 00:12:02.319 align:start position:0% actually use this hdl-c mechanism in 00:12:02.319 --> 00:12:03.990 align:start position:0% actually use this hdl-c mechanism in action<00:12:02.680> to<00:12:03.009> trustus<00:12:03.459> leak<00:12:03.699> through<00:12:03.879> your 00:12:03.990 --> 00:12:04.000 align:start position:0% action to trustus leak through your 00:12:04.000 --> 00:12:07.139 align:start position:0% action to trustus leak through your payment<00:12:04.360> so<00:12:04.990> in<00:12:05.290> that<00:12:05.439> case<00:12:05.879> the<00:12:06.879> on<00:12:07.029> J 00:12:07.139 --> 00:12:07.149 align:start position:0% payment so in that case the on J 00:12:07.149 --> 00:12:08.429 align:start position:0% payment so in that case the on J transaction<00:12:07.660> costs<00:12:07.930> are<00:12:08.050> closing<00:12:08.350> the 00:12:08.429 --> 00:12:08.439 align:start position:0% transaction costs are closing the 00:12:08.439 --> 00:12:10.019 align:start position:0% transaction costs are closing the channel<00:12:08.709> on<00:12:08.800> chain<00:12:09.069> might<00:12:09.279> actually<00:12:09.670> exceed 00:12:10.019 --> 00:12:10.029 align:start position:0% channel on chain might actually exceed 00:12:10.029 --> 00:12:12.720 align:start position:0% channel on chain might actually exceed the<00:12:10.149> dust<00:12:10.389> in<00:12:10.660> that<00:12:10.689> regard<00:12:11.500> our<00:12:11.649> channel<00:12:11.949> and 00:12:12.720 --> 00:12:12.730 align:start position:0% the dust in that regard our channel and 00:12:12.730 --> 00:12:14.670 align:start position:0% the dust in that regard our channel and lastly<00:12:13.240> there's<00:12:13.569> this<00:12:13.720> bonus<00:12:14.019> column<00:12:14.439> here 00:12:14.670 --> 00:12:14.680 align:start position:0% lastly there's this bonus column here 00:12:14.680 --> 00:12:16.230 align:start position:0% lastly there's this bonus column here this<00:12:14.920> is<00:12:15.069> a<00:12:15.100> there's<00:12:15.370> a<00:12:15.459> spot<00:12:15.639> is<00:12:15.790> right<00:12:15.970> here 00:12:16.230 --> 00:12:16.240 align:start position:0% this is a there's a spot is right here 00:12:16.240 --> 00:12:17.970 align:start position:0% this is a there's a spot is right here which<00:12:16.779> is<00:12:17.019> minimal<00:12:17.529> third<00:12:17.709> party 00:12:17.970 --> 00:12:17.980 align:start position:0% which is minimal third party 00:12:17.980 --> 00:12:19.889 align:start position:0% which is minimal third party infrastructure<00:12:18.459> dependence<00:12:18.910> this<00:12:19.120> isn't<00:12:19.810> a 00:12:19.889 --> 00:12:19.899 align:start position:0% infrastructure dependence this isn't a 00:12:19.899 --> 00:12:21.600 align:start position:0% infrastructure dependence this isn't a strict<00:12:20.170> requirement<00:12:20.740> but<00:12:20.920> it<00:12:21.100> would<00:12:21.279> be<00:12:21.430> nice 00:12:21.600 --> 00:12:21.610 align:start position:0% strict requirement but it would be nice 00:12:21.610 --> 00:12:23.309 align:start position:0% strict requirement but it would be nice if<00:12:21.880> you<00:12:22.029> can<00:12:22.120> accomplish<00:12:22.449> direct 00:12:23.309 --> 00:12:23.319 align:start position:0% if you can accomplish direct 00:12:23.319 --> 00:12:25.250 align:start position:0% if you can accomplish direct peer-to-peer<00:12:23.529> payments<00:12:24.160> without 00:12:25.250 --> 00:12:25.260 align:start position:0% peer-to-peer payments without 00:12:25.260 --> 00:12:27.449 align:start position:0% peer-to-peer payments without infrastructure<00:12:26.260> and<00:12:26.829> a<00:12:26.920> network<00:12:27.279> like 00:12:27.449 --> 00:12:27.459 align:start position:0% infrastructure and a network like 00:12:27.459 --> 00:12:28.949 align:start position:0% infrastructure and a network like lightning<00:12:27.790> you<00:12:27.910> need<00:12:28.089> two<00:12:28.240> reliable<00:12:28.660> real<00:12:28.810> air 00:12:28.949 --> 00:12:28.959 align:start position:0% lightning you need two reliable real air 00:12:28.959 --> 00:12:30.720 align:start position:0% lightning you need two reliable real air notes<00:12:29.230> which<00:12:29.740> might<00:12:29.920> be<00:12:30.040> okay<00:12:30.310> but<00:12:30.339> a 00:12:30.720 --> 00:12:30.730 align:start position:0% notes which might be okay but a 00:12:30.730 --> 00:12:32.460 align:start position:0% notes which might be okay but a nice-to-have<00:12:31.120> is<00:12:31.660> if<00:12:31.839> you<00:12:31.930> didn't<00:12:32.200> need<00:12:32.290> to<00:12:32.320> do 00:12:32.460 --> 00:12:32.470 align:start position:0% nice-to-have is if you didn't need to do 00:12:32.470 --> 00:12:35.280 align:start position:0% nice-to-have is if you didn't need to do that<00:12:33.360> the<00:12:34.360> second<00:12:34.660> construction<00:12:35.019> that's 00:12:35.280 --> 00:12:35.290 align:start position:0% that the second construction that's 00:12:35.290 --> 00:12:37.230 align:start position:0% that the second construction that's worth<00:12:35.470> talking<00:12:35.620> about<00:12:35.860> is<00:12:36.370> virtual<00:12:36.910> channel 00:12:37.230 --> 00:12:37.240 align:start position:0% worth talking about is virtual channel 00:12:37.240 --> 00:12:37.889 align:start position:0% worth talking about is virtual channel hub-and-spoke 00:12:37.889 --> 00:12:37.899 align:start position:0% hub-and-spoke 00:12:37.899 --> 00:12:41.430 align:start position:0% hub-and-spoke type<00:12:38.230> networks<00:12:39.070> so<00:12:39.519> the<00:12:40.269> general<00:12:40.959> idea<00:12:41.260> here 00:12:41.430 --> 00:12:41.440 align:start position:0% type networks so the general idea here 00:12:41.440 --> 00:12:43.829 align:start position:0% type networks so the general idea here is<00:12:41.860> that<00:12:41.890> rather<00:12:42.370> than<00:12:42.610> using<00:12:42.820> HDL<00:12:43.390> C's<00:12:43.600> to 00:12:43.829 --> 00:12:43.839 align:start position:0% is that rather than using HDL C's to 00:12:43.839 --> 00:12:45.630 align:start position:0% is that rather than using HDL C's to connect<00:12:44.140> different<00:12:44.920> payment<00:12:45.370> channels 00:12:45.630 --> 00:12:45.640 align:start position:0% connect different payment channels 00:12:45.640 --> 00:12:47.280 align:start position:0% connect different payment channels across<00:12:45.880> the<00:12:46.060> network<00:12:46.390> you<00:12:46.630> have<00:12:46.839> a<00:12:47.079> hub 00:12:47.280 --> 00:12:47.290 align:start position:0% across the network you have a hub 00:12:47.290 --> 00:12:49.350 align:start position:0% across the network you have a hub sitting<00:12:47.920> in<00:12:48.010> the<00:12:48.070> middle<00:12:48.250> all<00:12:48.940> parties 00:12:49.350 --> 00:12:49.360 align:start position:0% sitting in the middle all parties 00:12:49.360 --> 00:12:52.319 align:start position:0% sitting in the middle all parties connect<00:12:49.720> to<00:12:49.810> and<00:12:50.160> they<00:12:51.160> block<00:12:51.519> off<00:12:51.700> funds<00:12:52.089> to 00:12:52.319 --> 00:12:52.329 align:start position:0% connect to and they block off funds to 00:12:52.329 --> 00:12:54.060 align:start position:0% connect to and they block off funds to be<00:12:52.450> used<00:12:52.480> in<00:12:52.930> these<00:12:53.050> virtual<00:12:53.410> channels<00:12:53.769> that 00:12:54.060 --> 00:12:54.070 align:start position:0% be used in these virtual channels that 00:12:54.070 --> 00:12:55.889 align:start position:0% be used in these virtual channels that are<00:12:54.310> connecting<00:12:54.880> to<00:12:54.910> counterparty<00:12:55.600> so<00:12:55.779> as 00:12:55.889 --> 00:12:55.899 align:start position:0% are connecting to counterparty so as 00:12:55.899 --> 00:12:58.079 align:start position:0% are connecting to counterparty so as long<00:12:56.050> as<00:12:56.110> you<00:12:56.380> have<00:12:56.649> funds<00:12:57.279> with<00:12:57.550> the<00:12:57.670> hub<00:12:57.850> and 00:12:58.079 --> 00:12:58.089 align:start position:0% long as you have funds with the hub and 00:12:58.089 --> 00:12:59.730 align:start position:0% long as you have funds with the hub and as<00:12:58.329> long<00:12:58.480> as<00:12:58.510> the<00:12:58.690> hub<00:12:59.019> has<00:12:59.260> funds<00:12:59.500> with 00:12:59.730 --> 00:12:59.740 align:start position:0% as long as the hub has funds with 00:12:59.740 --> 00:13:01.949 align:start position:0% as long as the hub has funds with another<00:13:00.130> counterparty<00:13:01.089> you<00:13:01.510> can<00:13:01.660> create<00:13:01.899> a 00:13:01.949 --> 00:13:01.959 align:start position:0% another counterparty you can create a 00:13:01.959 --> 00:13:03.780 align:start position:0% another counterparty you can create a direct<00:13:02.320> channel<00:13:02.649> between<00:13:02.860> those<00:13:03.220> two<00:13:03.430> parties 00:13:03.780 --> 00:13:03.790 align:start position:0% direct channel between those two parties 00:13:03.790 --> 00:13:06.780 align:start position:0% direct channel between those two parties and<00:13:04.029> the<00:13:04.779> hub<00:13:04.959> just<00:13:05.170> needs<00:13:05.320> to<00:13:05.500> have<00:13:05.790> adequate 00:13:06.780 --> 00:13:06.790 align:start position:0% and the hub just needs to have adequate 00:13:06.790 --> 00:13:08.639 align:start position:0% and the hub just needs to have adequate amount<00:13:07.000> of<00:13:07.060> funds<00:13:07.329> in<00:13:07.570> order<00:13:07.660> to<00:13:07.870> block<00:13:08.079> those 00:13:08.639 --> 00:13:08.649 align:start position:0% amount of funds in order to block those 00:13:08.649 --> 00:13:11.910 align:start position:0% amount of funds in order to block those off<00:13:08.890> to<00:13:09.100> be<00:13:09.220> used<00:13:09.459> in<00:13:09.670> that<00:13:09.820> channel<00:13:10.920> but 00:13:11.910 --> 00:13:11.920 align:start position:0% off to be used in that channel but 00:13:11.920 --> 00:13:14.220 align:start position:0% off to be used in that channel but similarly<00:13:12.370> there<00:13:12.790> is<00:13:12.970> still<00:13:13.390> the<00:13:13.600> possibility 00:13:14.220 --> 00:13:14.230 align:start position:0% similarly there is still the possibility 00:13:14.230 --> 00:13:16.410 align:start position:0% similarly there is still the possibility of<00:13:14.680> dust<00:13:15.130> accumulating<00:13:15.850> in<00:13:16.000> the<00:13:16.029> channel<00:13:16.390> so 00:13:16.410 --> 00:13:16.420 align:start position:0% of dust accumulating in the channel so 00:13:16.420 --> 00:13:18.990 align:start position:0% of dust accumulating in the channel so you<00:13:16.720> can<00:13:17.079> imagine<00:13:17.709> a<00:13:17.980> scenario<00:13:18.130> where<00:13:18.459> you 00:13:18.990 --> 00:13:19.000 align:start position:0% you can imagine a scenario where you 00:13:19.000 --> 00:13:20.790 align:start position:0% you can imagine a scenario where you have<00:13:19.180> multiple<00:13:19.510> channels<00:13:20.110> connected<00:13:20.560> with 00:13:20.790 --> 00:13:20.800 align:start position:0% have multiple channels connected with 00:13:20.800 --> 00:13:23.250 align:start position:0% have multiple channels connected with the<00:13:20.980> same<00:13:21.190> counterparty<00:13:21.790> but<00:13:22.329> if<00:13:22.600> you<00:13:22.839> end<00:13:23.140> up 00:13:23.250 --> 00:13:23.260 align:start position:0% the same counterparty but if you end up 00:13:23.260 --> 00:13:24.750 align:start position:0% the same counterparty but if you end up in<00:13:23.380> a<00:13:23.440> scenario<00:13:23.620> where<00:13:23.950> your<00:13:24.250> counterparty 00:13:24.750 --> 00:13:24.760 align:start position:0% in a scenario where your counterparty 00:13:24.760 --> 00:13:27.449 align:start position:0% in a scenario where your counterparty goes<00:13:24.910> offline<00:13:25.300> or<00:13:25.600> is<00:13:25.690> unresponsive<00:13:26.079> in<00:13:26.800> order 00:13:27.449 --> 00:13:27.459 align:start position:0% goes offline or is unresponsive in order 00:13:27.459 --> 00:13:29.430 align:start position:0% goes offline or is unresponsive in order to<00:13:27.610> gather<00:13:28.269> the<00:13:28.600> dust<00:13:28.810> in<00:13:29.019> those<00:13:29.170> channels 00:13:29.430 --> 00:13:29.440 align:start position:0% to gather the dust in those channels 00:13:29.440 --> 00:13:31.620 align:start position:0% to gather the dust in those channels you're<00:13:29.769> going<00:13:29.920> to<00:13:29.980> end<00:13:30.130> up<00:13:30.250> needing<00:13:30.519> to 00:13:31.620 --> 00:13:31.630 align:start position:0% you're going to end up needing to 00:13:31.630 --> 00:13:33.210 align:start position:0% you're going to end up needing to actions<00:13:31.960> for<00:13:32.230> each<00:13:32.350> of<00:13:32.500> the<00:13:32.590> channels<00:13:32.830> so<00:13:33.040> in 00:13:33.210 --> 00:13:33.220 align:start position:0% actions for each of the channels so in 00:13:33.220 --> 00:13:36.060 align:start position:0% actions for each of the channels so in that<00:13:33.340> case<00:13:33.610> a<00:13:34.470> solution<00:13:35.470> to<00:13:35.560> this<00:13:35.680> would<00:13:35.920> just 00:13:36.060 --> 00:13:36.070 align:start position:0% that case a solution to this would just 00:13:36.070 --> 00:13:37.950 align:start position:0% that case a solution to this would just to<00:13:36.250> be<00:13:36.400> half<00:13:36.580> of<00:13:36.610> it<00:13:36.880> just<00:13:37.330> to<00:13:37.480> have<00:13:37.630> a<00:13:37.660> minimum 00:13:37.950 --> 00:13:37.960 align:start position:0% to be half of it just to have a minimum 00:13:37.960 --> 00:13:39.750 align:start position:0% to be half of it just to have a minimum value<00:13:38.020> transacted<00:13:38.770> requirement<00:13:39.310> which<00:13:39.730> is 00:13:39.750 --> 00:13:39.760 align:start position:0% value transacted requirement which is 00:13:39.760 --> 00:13:41.220 align:start position:0% value transacted requirement which is something<00:13:40.120> that<00:13:40.270> we're<00:13:40.420> curious<00:13:40.690> if<00:13:40.930> we<00:13:41.050> can 00:13:41.220 --> 00:13:41.230 align:start position:0% something that we're curious if we can 00:13:41.230 --> 00:13:43.620 align:start position:0% something that we're curious if we can go<00:13:41.680> without<00:13:41.980> and<00:13:42.400> similarly<00:13:42.910> we<00:13:43.180> rely<00:13:43.420> on<00:13:43.450> the 00:13:43.620 --> 00:13:43.630 align:start position:0% go without and similarly we rely on the 00:13:43.630 --> 00:13:45.630 align:start position:0% go without and similarly we rely on the hub<00:13:43.810> in<00:13:44.020> this<00:13:44.200> case<00:13:44.410> so<00:13:44.740> there<00:13:44.890> is<00:13:45.040> their<00:13:45.340> party 00:13:45.630 --> 00:13:45.640 align:start position:0% hub in this case so there is their party 00:13:45.640 --> 00:13:49.170 align:start position:0% hub in this case so there is their party data<00:13:45.820> structure<00:13:46.120> depends<00:13:47.220> so<00:13:48.220> in<00:13:48.520> summary<00:13:48.850> I 00:13:49.170 --> 00:13:49.180 align:start position:0% data structure depends so in summary I 00:13:49.180 --> 00:13:51.750 align:start position:0% data structure depends so in summary I think<00:13:49.240> some<00:13:49.690> of<00:13:49.810> the<00:13:49.930> advantages<00:13:50.590> of<00:13:50.890> public 00:13:51.750 --> 00:13:51.760 align:start position:0% think some of the advantages of public 00:13:51.760 --> 00:13:53.460 align:start position:0% think some of the advantages of public micro<00:13:52.060> payments<00:13:52.450> to<00:13:52.600> payment<00:13:52.930> channels<00:13:53.260> is 00:13:53.460 --> 00:13:53.470 align:start position:0% micro payments to payment channels is 00:13:53.470 --> 00:13:55.710 align:start position:0% micro payments to payment channels is the<00:13:54.280> no<00:13:54.550> minimum<00:13:54.910> value<00:13:55.180> transacted 00:13:55.710 --> 00:13:55.720 align:start position:0% the no minimum value transacted 00:13:55.720 --> 00:13:57.780 align:start position:0% the no minimum value transacted requirement<00:13:56.290> and<00:13:56.470> then<00:13:56.860> also<00:13:57.040> that<00:13:57.430> no<00:13:57.520> third 00:13:57.780 --> 00:13:57.790 align:start position:0% requirement and then also that no third 00:13:57.790 --> 00:13:59.730 align:start position:0% requirement and then also that no third party<00:13:58.120> and<00:13:58.240> construction<00:13:58.690> dependents<00:13:59.170> but 00:13:59.730 --> 00:13:59.740 align:start position:0% party and construction dependents but 00:13:59.740 --> 00:14:01.710 align:start position:0% party and construction dependents but there<00:14:00.040> are<00:14:00.130> disadvantages<00:14:00.340> as<00:14:01.030> well<00:14:01.060> so<00:14:01.540> they 00:14:01.710 --> 00:14:01.720 align:start position:0% there are disadvantages as well so they 00:14:01.720 --> 00:14:03.240 align:start position:0% there are disadvantages as well so they do<00:14:01.840> exit<00:14:02.110> lottery<00:14:02.380> technics<00:14:02.830> is<00:14:02.950> something 00:14:03.240 --> 00:14:03.250 align:start position:0% do exit lottery technics is something 00:14:03.250 --> 00:14:04.800 align:start position:0% do exit lottery technics is something that<00:14:03.400> you<00:14:03.520> need<00:14:03.670> to<00:14:03.760> deal<00:14:03.940> with<00:14:04.150> you<00:14:04.480> might<00:14:04.690> not 00:14:04.800 --> 00:14:04.810 align:start position:0% that you need to deal with you might not 00:14:04.810 --> 00:14:06.630 align:start position:0% that you need to deal with you might not have<00:14:05.020> an<00:14:05.170> application<00:14:05.710> that<00:14:05.920> can't<00:14:06.220> deal<00:14:06.430> with 00:14:06.630 --> 00:14:06.640 align:start position:0% have an application that can't deal with 00:14:06.640 --> 00:14:08.880 align:start position:0% have an application that can't deal with that<00:14:06.790> do<00:14:06.940> X<00:14:07.120> in<00:14:07.330> an<00:14:07.420> adequate<00:14:07.630> way<00:14:07.810> and<00:14:08.230> it<00:14:08.770> only 00:14:08.880 --> 00:14:08.890 align:start position:0% that do X in an adequate way and it only 00:14:08.890 --> 00:14:10.950 align:start position:0% that do X in an adequate way and it only works<00:14:09.190> in<00:14:09.340> high<00:14:09.490> volume<00:14:09.820> use<00:14:09.970> cases<00:14:10.180> so<00:14:10.600> if 00:14:10.950 --> 00:14:10.960 align:start position:0% works in high volume use cases so if 00:14:10.960 --> 00:14:12.210 align:start position:0% works in high volume use cases so if you're<00:14:11.140> not<00:14:11.230> sending<00:14:11.500> a<00:14:11.620> lot<00:14:11.740> of<00:14:11.860> tickets<00:14:11.980> for 00:14:12.210 --> 00:14:12.220 align:start position:0% you're not sending a lot of tickets for 00:14:12.220 --> 00:14:15.300 align:start position:0% you're not sending a lot of tickets for a<00:14:12.370> lot<00:14:12.580> of<00:14:12.870> small<00:14:13.870> chunks<00:14:14.200> of<00:14:14.320> service<00:14:14.650> and<00:14:14.950> it 00:14:15.300 --> 00:14:15.310 align:start position:0% a lot of small chunks of service and it 00:14:15.310 --> 00:14:16.590 align:start position:0% a lot of small chunks of service and it might<00:14:15.460> not<00:14:15.490> work<00:14:15.700> out<00:14:15.880> for<00:14:15.940> you<00:14:16.210> because<00:14:16.360> you 00:14:16.590 --> 00:14:16.600 align:start position:0% might not work out for you because you 00:14:16.600 --> 00:14:18.390 align:start position:0% might not work out for you because you can<00:14:16.630> never<00:14:16.930> rely<00:14:17.680> on<00:14:17.710> the<00:14:17.980> law<00:14:18.100> of<00:14:18.250> large 00:14:18.390 --> 00:14:18.400 align:start position:0% can never rely on the law of large 00:14:18.400 --> 00:14:22.080 align:start position:0% can never rely on the law of large numbers<00:14:18.490> for<00:14:19.030> the<00:14:19.600> payments<00:14:20.020> to<00:14:20.320> be<00:14:20.890> fair<00:14:21.850> in 00:14:22.080 --> 00:14:22.090 align:start position:0% numbers for the payments to be fair in 00:14:22.090 --> 00:14:24.210 align:start position:0% numbers for the payments to be fair in the<00:14:22.180> long<00:14:22.330> term<00:14:22.510> and<00:14:23.110> something<00:14:24.040> that<00:14:24.100> I'll 00:14:24.210 --> 00:14:24.220 align:start position:0% the long term and something that I'll 00:14:24.220 --> 00:14:25.680 align:start position:0% the long term and something that I'll talk<00:14:24.340> about<00:14:24.400> a<00:14:24.610> little<00:14:24.670> bit<00:14:24.910> is<00:14:25.240> you<00:14:25.540> might 00:14:25.680 --> 00:14:25.690 align:start position:0% talk about a little bit is you might 00:14:25.690 --> 00:14:26.940 align:start position:0% talk about a little bit is you might have<00:14:25.720> higher<00:14:26.050> personal<00:14:26.470> collateral 00:14:26.940 --> 00:14:26.950 align:start position:0% have higher personal collateral 00:14:26.950 --> 00:14:28.860 align:start position:0% have higher personal collateral requirements<00:14:27.070> as<00:14:27.580> well<00:14:27.730> because<00:14:28.180> you<00:14:28.630> can't 00:14:28.860 --> 00:14:28.870 align:start position:0% requirements as well because you can't 00:14:28.870 --> 00:14:30.660 align:start position:0% requirements as well because you can't rely<00:14:29.110> on<00:14:29.170> a<00:14:29.350> third<00:14:29.530> party<00:14:29.560> to<00:14:29.950> provide<00:14:30.160> equity 00:14:30.660 --> 00:14:30.670 align:start position:0% rely on a third party to provide equity 00:14:30.670 --> 00:14:33.960 align:start position:0% rely on a third party to provide equity for<00:14:30.850> you<00:14:31.470> so<00:14:32.470> moving<00:14:32.770> on<00:14:32.890> to<00:14:33.100> the<00:14:33.580> security 00:14:33.960 --> 00:14:33.970 align:start position:0% for you so moving on to the security 00:14:33.970 --> 00:14:35.490 align:start position:0% for you so moving on to the security model<00:14:34.120> there's<00:14:34.600> different<00:14:35.050> aspects<00:14:35.410> into 00:14:35.490 --> 00:14:35.500 align:start position:0% model there's different aspects into 00:14:35.500 --> 00:14:37.080 align:start position:0% model there's different aspects into this<00:14:35.620> but<00:14:35.860> I'll<00:14:35.950> focus<00:14:36.100> on<00:14:36.460> two<00:14:36.760> particular 00:14:37.080 --> 00:14:37.090 align:start position:0% this but I'll focus on two particular 00:14:37.090 --> 00:14:39.240 align:start position:0% this but I'll focus on two particular components<00:14:37.720> so<00:14:37.840> the<00:14:37.930> first<00:14:38.110> one<00:14:38.320> is<00:14:38.560> the 00:14:39.240 --> 00:14:39.250 align:start position:0% components so the first one is the 00:14:39.250 --> 00:14:41.910 align:start position:0% components so the first one is the winning<00:14:39.520> ticket<00:14:39.850> selection<00:14:40.240> protocol<00:14:40.920> so 00:14:41.910 --> 00:14:41.920 align:start position:0% winning ticket selection protocol so 00:14:41.920 --> 00:14:43.980 align:start position:0% winning ticket selection protocol so this<00:14:42.520> is<00:14:42.730> really<00:14:42.940> important<00:14:43.300> because<00:14:43.330> if<00:14:43.900> you 00:14:43.980 --> 00:14:43.990 align:start position:0% this is really important because if you 00:14:43.990 --> 00:14:45.150 align:start position:0% this is really important because if you don't<00:14:44.140> have<00:14:44.320> a<00:14:44.350> fair<00:14:44.620> winning<00:14:44.890> ticket 00:14:45.150 --> 00:14:45.160 align:start position:0% don't have a fair winning ticket 00:14:45.160 --> 00:14:48.120 align:start position:0% don't have a fair winning ticket selection<00:14:45.550> protocol<00:14:46.030> then<00:14:46.650> if<00:14:47.650> someone<00:14:48.010> can 00:14:48.120 --> 00:14:48.130 align:start position:0% selection protocol then if someone can 00:14:48.130 --> 00:14:50.610 align:start position:0% selection protocol then if someone can influence<00:14:48.550> which<00:14:48.940> tickets<00:14:49.420> win<00:14:49.810> then<00:14:50.170> this 00:14:50.610 --> 00:14:50.620 align:start position:0% influence which tickets win then this 00:14:50.620 --> 00:14:52.200 align:start position:0% influence which tickets win then this isn't<00:14:50.980> going<00:14:51.100> to<00:14:51.280> be<00:14:51.400> a<00:14:51.430> fair<00:14:51.670> payment<00:14:52.000> scheme 00:14:52.200 --> 00:14:52.210 align:start position:0% isn't going to be a fair payment scheme 00:14:52.210 --> 00:14:54.990 align:start position:0% isn't going to be a fair payment scheme so<00:14:52.840> this<00:14:53.260> is<00:14:53.440> just<00:14:53.620> one<00:14:53.950> way<00:14:53.980> to<00:14:54.250> do<00:14:54.640> it<00:14:54.760> there's 00:14:54.990 --> 00:14:55.000 align:start position:0% so this is just one way to do it there's 00:14:55.000 --> 00:14:56.280 align:start position:0% so this is just one way to do it there's multiple<00:14:55.360> different<00:14:55.510> ways<00:14:55.690> that<00:14:56.020> you<00:14:56.140> can 00:14:56.280 --> 00:14:56.290 align:start position:0% multiple different ways that you can 00:14:56.290 --> 00:14:58.620 align:start position:0% multiple different ways that you can achieve<00:14:56.470> this<00:14:57.070> fair<00:14:57.490> selection<00:14:57.820> protocol<00:14:58.390> and 00:14:58.620 --> 00:14:58.630 align:start position:0% achieve this fair selection protocol and 00:14:58.630 --> 00:15:00.030 align:start position:0% achieve this fair selection protocol and the<00:14:58.870> way<00:14:58.990> that<00:14:59.170> we<00:14:59.260> do<00:14:59.380> it<00:14:59.500> is<00:14:59.650> via<00:14:59.860> this 00:15:00.030 --> 00:15:00.040 align:start position:0% the way that we do it is via this 00:15:00.040 --> 00:15:02.550 align:start position:0% the way that we do it is via this command<00:15:00.520> reveal<00:15:00.820> scheme<00:15:01.120> and<00:15:01.360> the<00:15:02.260> command 00:15:02.550 --> 00:15:02.560 align:start position:0% command reveal scheme and the command 00:15:02.560 --> 00:15:04.260 align:start position:0% command reveal scheme and the command reveal<00:15:02.770> scheme<00:15:03.070> basically<00:15:03.490> has<00:15:04.000> the 00:15:04.260 --> 00:15:04.270 align:start position:0% reveal scheme basically has the 00:15:04.270 --> 00:15:07.080 align:start position:0% reveal scheme basically has the recipient<00:15:04.810> defined<00:15:05.380> a<00:15:05.530> hash<00:15:05.740> of<00:15:06.090> random 00:15:07.080 --> 00:15:07.090 align:start position:0% recipient defined a hash of random 00:15:07.090 --> 00:15:09.420 align:start position:0% recipient defined a hash of random number<00:15:07.330> data<00:15:07.600> keeps<00:15:07.870> secret<00:15:08.200> and<00:15:08.380> the<00:15:09.070> sender 00:15:09.420 --> 00:15:09.430 align:start position:0% number data keeps secret and the sender 00:15:09.430 --> 00:15:11.370 align:start position:0% number data keeps secret and the sender includes<00:15:09.940> a<00:15:10.180> monotonically<00:15:10.780> increasing 00:15:11.370 --> 00:15:11.380 align:start position:0% includes a monotonically increasing 00:15:11.380 --> 00:15:13.620 align:start position:0% includes a monotonically increasing sender<00:15:11.830> nuts<00:15:12.010> and<00:15:12.280> it<00:15:12.880> maintains<00:15:13.150> a<00:15:13.300> separate 00:15:13.620 --> 00:15:13.630 align:start position:0% sender nuts and it maintains a separate 00:15:13.630 --> 00:15:15.570 align:start position:0% sender nuts and it maintains a separate counter<00:15:13.990> for<00:15:14.320> each<00:15:14.470> of<00:15:14.650> these<00:15:14.740> hashes<00:15:14.980> and<00:15:15.370> the 00:15:15.570 --> 00:15:15.580 align:start position:0% counter for each of these hashes and the 00:15:15.580 --> 00:15:18.060 align:start position:0% counter for each of these hashes and the idea<00:15:15.850> is<00:15:16.000> that<00:15:16.030> the<00:15:16.600> ticket<00:15:16.780> will<00:15:16.990> win<00:15:17.170> if<00:15:17.380> we 00:15:18.060 --> 00:15:18.070 align:start position:0% idea is that the ticket will win if we 00:15:18.070 --> 00:15:19.910 align:start position:0% idea is that the ticket will win if we have<00:15:18.250> these<00:15:18.730> two<00:15:18.970> random<00:15:19.150> numbers<00:15:19.540> thing 00:15:19.910 --> 00:15:19.920 align:start position:0% have these two random numbers thing 00:15:19.920 --> 00:15:21.530 align:start position:0% have these two random numbers thing where<00:15:20.129> we<00:15:20.339> hash<00:15:20.549> the<00:15:20.819> recipients<00:15:21.269> random 00:15:21.530 --> 00:15:21.540 align:start position:0% where we hash the recipients random 00:15:21.540 --> 00:15:23.569 align:start position:0% where we hash the recipients random number<00:15:21.749> and<00:15:21.869> then<00:15:22.439> we<00:15:22.589> use<00:15:22.859> the<00:15:23.160> signature 00:15:23.569 --> 00:15:23.579 align:start position:0% number and then we use the signature 00:15:23.579 --> 00:15:26.239 align:start position:0% number and then we use the signature over<00:15:23.970> the<00:15:24.119> ticket<00:15:24.420> as<00:15:24.600> the<00:15:25.559> random<00:15:25.859> number<00:15:26.100> for 00:15:26.239 --> 00:15:26.249 align:start position:0% over the ticket as the random number for 00:15:26.249 --> 00:15:28.039 align:start position:0% over the ticket as the random number for the<00:15:26.369> sender<00:15:26.670> and<00:15:26.790> the<00:15:27.389> idea<00:15:27.629> behind<00:15:27.779> the 00:15:28.039 --> 00:15:28.049 align:start position:0% the sender and the idea behind the 00:15:28.049 --> 00:15:28.609 align:start position:0% the sender and the idea behind the sender<00:15:28.290> nots 00:15:28.609 --> 00:15:28.619 align:start position:0% sender nots 00:15:28.619 --> 00:15:30.109 align:start position:0% sender nots is<00:15:28.739> that<00:15:29.009> we<00:15:29.189> need<00:15:29.339> something<00:15:29.549> that<00:15:29.790> makes<00:15:29.819> the 00:15:30.109 --> 00:15:30.119 align:start position:0% is that we need something that makes the 00:15:30.119 --> 00:15:31.759 align:start position:0% is that we need something that makes the hasha<00:15:30.329> to<00:15:30.540> take<00:15:30.720> it<00:15:30.809> unique<00:15:31.109> such<00:15:31.410> that<00:15:31.589> once 00:15:31.759 --> 00:15:31.769 align:start position:0% hasha to take it unique such that once 00:15:31.769 --> 00:15:33.829 align:start position:0% hasha to take it unique such that once you<00:15:31.980> produce<00:15:32.489> a<00:15:32.759> signature<00:15:33.089> or<00:15:33.359> that<00:15:33.629> hash 00:15:33.829 --> 00:15:33.839 align:start position:0% you produce a signature or that hash 00:15:33.839 --> 00:15:36.889 align:start position:0% you produce a signature or that hash it's<00:15:34.379> unpredictable<00:15:34.829> to<00:15:35.670> the<00:15:36.179> recipient<00:15:36.689> and 00:15:36.889 --> 00:15:36.899 align:start position:0% it's unpredictable to the recipient and 00:15:36.899 --> 00:15:39.259 align:start position:0% it's unpredictable to the recipient and then<00:15:37.319> if<00:15:37.589> that<00:15:37.799> hash<00:15:38.040> number<00:15:38.459> is<00:15:38.730> below<00:15:39.029> the 00:15:39.259 --> 00:15:39.269 align:start position:0% then if that hash number is below the 00:15:39.269 --> 00:15:40.789 align:start position:0% then if that hash number is below the winning<00:15:39.480> probability<00:15:39.629> that<00:15:40.169> we<00:15:40.290> consider<00:15:40.649> the 00:15:40.789 --> 00:15:40.799 align:start position:0% winning probability that we consider the 00:15:40.799 --> 00:15:44.059 align:start position:0% winning probability that we consider the ticket<00:15:41.100> opener<00:15:41.869> so<00:15:42.869> the<00:15:43.109> basic<00:15:43.379> idea<00:15:43.470> here<00:15:43.709> is 00:15:44.059 --> 00:15:44.069 align:start position:0% ticket opener so the basic idea here is 00:15:44.069 --> 00:15:45.499 align:start position:0% ticket opener so the basic idea here is that<00:15:44.100> the<00:15:44.429> recipient<00:15:44.879> should<00:15:44.970> not<00:15:45.119> be<00:15:45.269> able<00:15:45.389> to 00:15:45.499 --> 00:15:45.509 align:start position:0% that the recipient should not be able to 00:15:45.509 --> 00:15:47.359 align:start position:0% that the recipient should not be able to manipulate<00:15:45.749> selection<00:15:46.529> as<00:15:46.889> long<00:15:47.129> as<00:15:47.249> it 00:15:47.359 --> 00:15:47.369 align:start position:0% manipulate selection as long as it 00:15:47.369 --> 00:15:48.829 align:start position:0% manipulate selection as long as it cannot<00:15:47.609> predict<00:15:47.999> the<00:15:48.149> signature<00:15:48.569> that<00:15:48.720> the 00:15:48.829 --> 00:15:48.839 align:start position:0% cannot predict the signature that the 00:15:48.839 --> 00:15:50.419 align:start position:0% cannot predict the signature that the sender's<00:15:49.139> gonna<00:15:49.350> produce<00:15:49.529> over<00:15:49.980> the<00:15:50.160> ticket 00:15:50.419 --> 00:15:50.429 align:start position:0% sender's gonna produce over the ticket 00:15:50.429 --> 00:15:52.909 align:start position:0% sender's gonna produce over the ticket hash<00:15:50.609> and<00:15:50.879> then<00:15:51.540> the<00:15:51.869> sender<00:15:52.169> should<00:15:52.439> not<00:15:52.769> be 00:15:52.909 --> 00:15:52.919 align:start position:0% hash and then the sender should not be 00:15:52.919 --> 00:15:54.619 align:start position:0% hash and then the sender should not be able<00:15:53.040> to<00:15:53.160> manipulate<00:15:53.339> selection<00:15:54.059> as<00:15:54.359> long<00:15:54.540> as 00:15:54.619 --> 00:15:54.629 align:start position:0% able to manipulate selection as long as 00:15:54.629 --> 00:15:56.419 align:start position:0% able to manipulate selection as long as it<00:15:54.749> does<00:15:54.899> not<00:15:54.929> know<00:15:55.259> the<00:15:55.470> secret<00:15:55.799> number<00:15:56.100> that 00:15:56.419 --> 00:15:56.429 align:start position:0% it does not know the secret number that 00:15:56.429 --> 00:15:59.599 align:start position:0% it does not know the secret number that the<00:15:56.989> recipient<00:15:57.989> has<00:15:58.019> generated<00:15:58.410> so<00:15:59.339> the<00:15:59.429> only 00:15:59.599 --> 00:15:59.609 align:start position:0% the recipient has generated so the only 00:15:59.609 --> 00:16:00.679 align:start position:0% the recipient has generated so the only thing<00:15:59.850> that<00:15:59.879> recipient<00:16:00.269> repeat<00:16:00.600> we're 00:16:00.679 --> 00:16:00.689 align:start position:0% thing that recipient repeat we're 00:16:00.689 --> 00:16:02.590 align:start position:0% thing that recipient repeat we're dealing<00:16:00.989> here<00:16:01.019> is<00:16:01.439> the<00:16:01.739> hash<00:16:01.919> of<00:16:02.220> that<00:16:02.249> number 00:16:02.590 --> 00:16:02.600 align:start position:0% dealing here is the hash of that number 00:16:02.600 --> 00:16:04.669 align:start position:0% dealing here is the hash of that number it's<00:16:03.600> important<00:16:03.869> to<00:16:03.929> note<00:16:04.079> that<00:16:04.109> the 00:16:04.669 --> 00:16:04.679 align:start position:0% it's important to note that the 00:16:04.679 --> 00:16:06.109 align:start position:0% it's important to note that the recipient<00:16:05.069> also<00:16:05.249> needs<00:16:05.459> to<00:16:05.549> defend<00:16:05.790> itself 00:16:06.109 --> 00:16:06.119 align:start position:0% recipient also needs to defend itself 00:16:06.119 --> 00:16:08.179 align:start position:0% recipient also needs to defend itself against<00:16:06.509> replay<00:16:06.779> attacks<00:16:06.869> so<00:16:07.470> it<00:16:08.009> should 00:16:08.179 --> 00:16:08.189 align:start position:0% against replay attacks so it should 00:16:08.189 --> 00:16:10.429 align:start position:0% against replay attacks so it should never<00:16:08.279> accept<00:16:08.790> the<00:16:08.939> ticket<00:16:09.209> if<00:16:09.449> it's<00:16:09.959> using<00:16:10.379> a 00:16:10.429 --> 00:16:10.439 align:start position:0% never accept the ticket if it's using a 00:16:10.439 --> 00:16:12.619 align:start position:0% never accept the ticket if it's using a hash<00:16:10.850> such<00:16:11.850> that<00:16:12.029> that<00:16:12.149> poppy<00:16:12.299> image<00:16:12.480> has 00:16:12.619 --> 00:16:12.629 align:start position:0% hash such that that poppy image has 00:16:12.629 --> 00:16:14.119 align:start position:0% hash such that that poppy image has already<00:16:12.749> been<00:16:13.049> revealed<00:16:13.259> because<00:16:13.679> then<00:16:14.009> you 00:16:14.119 --> 00:16:14.129 align:start position:0% already been revealed because then you 00:16:14.129 --> 00:16:16.400 align:start position:0% already been revealed because then you know<00:16:14.279> the<00:16:14.489> secret<00:16:14.759> number<00:16:14.999> and<00:16:15.269> it<00:16:16.199> should 00:16:16.400 --> 00:16:16.410 align:start position:0% know the secret number and it should 00:16:16.410 --> 00:16:18.109 align:start position:0% know the secret number and it should also<00:16:16.649> not<00:16:16.919> accepting<00:16:17.429> its<00:16:17.579> width<00:16:17.759> and<00:16:17.910> already 00:16:18.109 --> 00:16:18.119 align:start position:0% also not accepting its width and already 00:16:18.119 --> 00:16:20.389 align:start position:0% also not accepting its width and already used<00:16:18.419> nots<00:16:18.720> so<00:16:19.139> if<00:16:19.499> it's<00:16:19.739> using<00:16:20.069> and<00:16:20.189> already 00:16:20.389 --> 00:16:20.399 align:start position:0% used nots so if it's using and already 00:16:20.399 --> 00:16:22.099 align:start position:0% used nots so if it's using and already use<00:16:20.609> nots<00:16:20.879> then<00:16:21.179> the<00:16:21.449> person<00:16:21.779> already<00:16:21.989> knows 00:16:22.099 --> 00:16:22.109 align:start position:0% use nots then the person already knows 00:16:22.109 --> 00:16:24.139 align:start position:0% use nots then the person already knows that<00:16:22.319> it's<00:16:22.829> not<00:16:22.949> going<00:16:23.339> to<00:16:23.489> produce<00:16:23.669> a<00:16:23.939> winning 00:16:24.139 --> 00:16:24.149 align:start position:0% that it's not going to produce a winning 00:16:24.149 --> 00:16:26.359 align:start position:0% that it's not going to produce a winning ticket<00:16:24.239> so<00:16:25.139> you<00:16:25.589> want<00:16:25.769> to<00:16:25.860> make<00:16:25.980> sure<00:16:26.009> that<00:16:26.249> you 00:16:26.359 --> 00:16:26.369 align:start position:0% ticket so you want to make sure that you 00:16:26.369 --> 00:16:28.159 align:start position:0% ticket so you want to make sure that you defend<00:16:27.029> yourself<00:16:27.389> against<00:16:27.689> those<00:16:27.839> types<00:16:28.079> of 00:16:28.159 --> 00:16:28.169 align:start position:0% defend yourself against those types of 00:16:28.169 --> 00:16:30.439 align:start position:0% defend yourself against those types of attacks<00:16:28.470> as<00:16:28.619> well<00:16:28.769> and<00:16:29.119> the<00:16:30.119> on<00:16:30.269> chain 00:16:30.439 --> 00:16:30.449 align:start position:0% attacks as well and the on chain 00:16:30.449 --> 00:16:32.119 align:start position:0% attacks as well and the on chain contract<00:16:30.899> makes<00:16:31.199> sure<00:16:31.319> to<00:16:31.470> record<00:16:31.769> the<00:16:31.980> use 00:16:32.119 --> 00:16:32.129 align:start position:0% contract makes sure to record the use 00:16:32.129 --> 00:16:34.669 align:start position:0% contract makes sure to record the use tickets<00:16:32.489> to<00:16:32.759> prevent<00:16:33.119> replace<00:16:33.480> so<00:16:33.839> we<00:16:34.470> want<00:16:34.619> to 00:16:34.669 --> 00:16:34.679 align:start position:0% tickets to prevent replace so we want to 00:16:34.679 --> 00:16:35.840 align:start position:0% tickets to prevent replace so we want to make<00:16:34.799> sure<00:16:34.829> that<00:16:35.040> you<00:16:35.160> can't<00:16:35.399> redeem<00:16:35.639> a 00:16:35.840 --> 00:16:35.850 align:start position:0% make sure that you can't redeem a 00:16:35.850 --> 00:16:38.900 align:start position:0% make sure that you can't redeem a waiting<00:16:36.089> to<00:16:36.179> get<00:16:36.299> more<00:16:36.509> than<00:16:36.720> once<00:16:37.579> the<00:16:38.579> second 00:16:38.900 --> 00:16:38.910 align:start position:0% waiting to get more than once the second 00:16:38.910 --> 00:16:40.400 align:start position:0% waiting to get more than once the second problem<00:16:39.269> that's<00:16:39.509> worth<00:16:39.660> highlighting<00:16:39.839> is 00:16:40.400 --> 00:16:40.410 align:start position:0% problem that's worth highlighting is 00:16:40.410 --> 00:16:43.549 align:start position:0% problem that's worth highlighting is double<00:16:40.949> Spence<00:16:41.160> so<00:16:41.549> in<00:16:42.149> the<00:16:42.869> past<00:16:43.049> literature 00:16:43.549 --> 00:16:43.559 align:start position:0% double Spence so in the past literature 00:16:43.559 --> 00:16:46.220 align:start position:0% double Spence so in the past literature the<00:16:43.769> most<00:16:43.799> common<00:16:44.329> naive<00:16:45.329> protocol<00:16:45.779> is<00:16:45.929> using 00:16:46.220 --> 00:16:46.230 align:start position:0% the most common naive protocol is using 00:16:46.230 --> 00:16:48.319 align:start position:0% the most common naive protocol is using a<00:16:46.290> single<00:16:46.589> launching<00:16:46.919> deposit<00:16:47.399> but<00:16:48.269> the 00:16:48.319 --> 00:16:48.329 align:start position:0% a single launching deposit but the 00:16:48.329 --> 00:16:49.909 align:start position:0% a single launching deposit but the problem<00:16:48.569> here<00:16:48.720> is<00:16:48.779> that<00:16:48.899> a<00:16:49.259> malicious<00:16:49.589> sender 00:16:49.909 --> 00:16:49.919 align:start position:0% problem here is that a malicious sender 00:16:49.919 --> 00:16:52.220 align:start position:0% problem here is that a malicious sender can't<00:16:50.249> send<00:16:50.519> multiple<00:16:50.999> tickets<00:16:51.119> to<00:16:51.569> multiple 00:16:52.220 --> 00:16:52.230 align:start position:0% can't send multiple tickets to multiple 00:16:52.230 --> 00:16:54.409 align:start position:0% can't send multiple tickets to multiple providers<00:16:52.499> and<00:16:52.949> if<00:16:53.189> they<00:16:53.339> all<00:16:53.489> win<00:16:53.699> you<00:16:54.269> might 00:16:54.409 --> 00:16:54.419 align:start position:0% providers and if they all win you might 00:16:54.419 --> 00:16:55.130 align:start position:0% providers and if they all win you might not<00:16:54.540> have<00:16:54.689> enough 00:16:55.130 --> 00:16:55.140 align:start position:0% not have enough 00:16:55.140 --> 00:16:56.690 align:start position:0% not have enough your<00:16:55.470> deposit<00:16:55.860> to<00:16:56.040> fund<00:16:56.250> all<00:16:56.370> those<00:16:56.550> many 00:16:56.690 --> 00:16:56.700 align:start position:0% your deposit to fund all those many 00:16:56.700 --> 00:16:58.730 align:start position:0% your deposit to fund all those many tickets<00:16:56.940> so<00:16:57.450> the<00:16:57.990> classic<00:16:58.320> double<00:16:58.529> spent 00:16:58.730 --> 00:16:58.740 align:start position:0% tickets so the classic double spent 00:16:58.740 --> 00:17:00.650 align:start position:0% tickets so the classic double spent problem<00:16:59.040> and<00:16:59.279> this<00:16:59.850> is<00:17:00.000> just<00:17:00.149> an<00:17:00.269> illustration 00:17:00.650 --> 00:17:00.660 align:start position:0% problem and this is just an illustration 00:17:00.660 --> 00:17:02.180 align:start position:0% problem and this is just an illustration of<00:17:00.870> this<00:17:00.990> where<00:17:01.260> we<00:17:01.290> have<00:17:01.500> three<00:17:01.709> recipients 00:17:02.180 --> 00:17:02.190 align:start position:0% of this where we have three recipients 00:17:02.190 --> 00:17:03.530 align:start position:0% of this where we have three recipients they<00:17:02.339> all<00:17:02.459> receive<00:17:02.790> winning<00:17:03.029> tickets<00:17:03.329> with<00:17:03.480> a 00:17:03.530 --> 00:17:03.540 align:start position:0% they all receive winning tickets with a 00:17:03.540 --> 00:17:05.900 align:start position:0% they all receive winning tickets with a face<00:17:03.720> value<00:17:03.750> of<00:17:04.140> five<00:17:04.350> but<00:17:05.069> the<00:17:05.370> on<00:17:05.490> to<00:17:05.640> deposit 00:17:05.900 --> 00:17:05.910 align:start position:0% face value of five but the on to deposit 00:17:05.910 --> 00:17:08.000 align:start position:0% face value of five but the on to deposit only<00:17:06.270> has<00:17:06.420> five<00:17:06.630> ether<00:17:06.929> in<00:17:07.049> it<00:17:07.199> and<00:17:07.410> we<00:17:07.770> can<00:17:07.890> see 00:17:08.000 --> 00:17:08.010 align:start position:0% only has five ether in it and we can see 00:17:08.010 --> 00:17:09.530 align:start position:0% only has five ether in it and we can see that<00:17:08.160> it's<00:17:08.309> fine<00:17:08.520> for<00:17:08.790> the<00:17:08.850> first<00:17:08.880> redemption 00:17:09.530 --> 00:17:09.540 align:start position:0% that it's fine for the first redemption 00:17:09.540 --> 00:17:11.419 align:start position:0% that it's fine for the first redemption that<00:17:09.959> a<00:17:10.049> second<00:17:10.380> their<00:17:10.770> redemptions<00:17:11.280> are 00:17:11.419 --> 00:17:11.429 align:start position:0% that a second their redemptions are 00:17:11.429 --> 00:17:12.500 align:start position:0% that a second their redemptions are happy<00:17:11.640> to<00:17:11.730> be<00:17:11.819> able<00:17:11.850> to<00:17:12.059> clear<00:17:12.299> because 00:17:12.500 --> 00:17:12.510 align:start position:0% happy to be able to clear because 00:17:12.510 --> 00:17:17.179 align:start position:0% happy to be able to clear because there's<00:17:12.720> not<00:17:12.809> enough<00:17:13.049> funds<00:17:13.670> so<00:17:14.670> the<00:17:15.770> idea<00:17:16.770> as 00:17:17.179 --> 00:17:17.189 align:start position:0% there's not enough funds so the idea as 00:17:17.189 --> 00:17:19.039 align:start position:0% there's not enough funds so the idea as you<00:17:17.309> solve<00:17:17.640> this<00:17:17.819> is<00:17:18.059> setting<00:17:18.480> a<00:17:18.569> collateral 00:17:19.039 --> 00:17:19.049 align:start position:0% you solve this is setting a collateral 00:17:19.049 --> 00:17:20.929 align:start position:0% you solve this is setting a collateral apartment<00:17:19.470> that<00:17:19.740> is<00:17:20.130> greater<00:17:20.459> than<00:17:20.610> or<00:17:20.699> equal 00:17:20.929 --> 00:17:20.939 align:start position:0% apartment that is greater than or equal 00:17:20.939 --> 00:17:22.579 align:start position:0% apartment that is greater than or equal to<00:17:21.059> that<00:17:21.150> maximum<00:17:21.480> utility<00:17:21.809> or<00:17:22.350> double 00:17:22.579 --> 00:17:22.589 align:start position:0% to that maximum utility or double 00:17:22.589 --> 00:17:24.500 align:start position:0% to that maximum utility or double spending<00:17:22.829> so<00:17:23.610> when<00:17:23.760> I<00:17:23.790> only<00:17:24.030> used<00:17:24.270> in<00:17:24.390> other 00:17:24.500 --> 00:17:24.510 align:start position:0% spending so when I only used in other 00:17:24.510 --> 00:17:25.910 align:start position:0% spending so when I only used in other types<00:17:24.750> of<00:17:24.809> protocol<00:17:25.079> is<00:17:25.380> washing<00:17:25.799> the 00:17:25.910 --> 00:17:25.920 align:start position:0% types of protocol is washing the 00:17:25.920 --> 00:17:28.250 align:start position:0% types of protocol is washing the collateral<00:17:26.339> but<00:17:27.299> instead<00:17:27.600> we<00:17:27.870> can<00:17:28.020> have<00:17:28.169> the 00:17:28.250 --> 00:17:28.260 align:start position:0% collateral but instead we can have the 00:17:28.260 --> 00:17:29.780 align:start position:0% collateral but instead we can have the recipients<00:17:28.710> claim<00:17:28.980> from<00:17:29.220> a<00:17:29.309> reserve<00:17:29.580> that 00:17:29.780 --> 00:17:29.790 align:start position:0% recipients claim from a reserve that 00:17:29.790 --> 00:17:31.310 align:start position:0% recipients claim from a reserve that guarantees<00:17:30.299> the<00:17:30.450> recipients<00:17:30.960> up<00:17:31.140> to<00:17:31.290> a 00:17:31.310 --> 00:17:31.320 align:start position:0% guarantees the recipients up to a 00:17:31.320 --> 00:17:34.669 align:start position:0% guarantees the recipients up to a predefined<00:17:31.860> amount<00:17:32.929> I'm<00:17:33.929> gonna<00:17:34.080> skip<00:17:34.530> over 00:17:34.669 --> 00:17:34.679 align:start position:0% predefined amount I'm gonna skip over 00:17:34.679 --> 00:17:36.200 align:start position:0% predefined amount I'm gonna skip over this<00:17:34.919> because<00:17:35.160> we're<00:17:35.400> running<00:17:35.520> a<00:17:35.850> little<00:17:36.000> low 00:17:36.200 --> 00:17:36.210 align:start position:0% this because we're running a little low 00:17:36.210 --> 00:17:38.419 align:start position:0% this because we're running a little low on<00:17:36.240> time<00:17:36.570> but<00:17:36.929> the<00:17:37.169> general<00:17:37.530> idea<00:17:37.590> is<00:17:37.860> that<00:17:38.250> the 00:17:38.419 --> 00:17:38.429 align:start position:0% on time but the general idea is that the 00:17:38.429 --> 00:17:41.150 align:start position:0% on time but the general idea is that the reserve<00:17:38.730> basically<00:17:39.620> presents<00:17:40.620> a<00:17:40.679> maximum 00:17:41.150 --> 00:17:41.160 align:start position:0% reserve basically presents a maximum 00:17:41.160 --> 00:17:42.710 align:start position:0% reserve basically presents a maximum allocation<00:17:41.700> committed<00:17:42.150> to<00:17:42.299> each<00:17:42.480> recipient 00:17:42.710 --> 00:17:42.720 align:start position:0% allocation committed to each recipient 00:17:42.720 --> 00:17:45.950 align:start position:0% allocation committed to each recipient and<00:17:43.260> as<00:17:44.130> a<00:17:44.190> result<00:17:44.580> we<00:17:45.090> can<00:17:45.120> keep<00:17:45.450> track<00:17:45.630> of<00:17:45.690> a 00:17:45.950 --> 00:17:45.960 align:start position:0% and as a result we can keep track of a 00:17:45.960 --> 00:17:48.049 align:start position:0% and as a result we can keep track of a float<00:17:46.200> for<00:17:46.230> the<00:17:46.530> senator<00:17:46.950> where<00:17:47.250> the<00:17:47.700> float<00:17:47.910> is 00:17:48.049 --> 00:17:48.059 align:start position:0% float for the senator where the float is 00:17:48.059 --> 00:17:50.090 align:start position:0% float for the senator where the float is money<00:17:48.270> that<00:17:48.360> the<00:17:48.510> payee<00:17:48.720> receives<00:17:49.169> but<00:17:49.620> due<00:17:50.070> to 00:17:50.090 --> 00:17:50.100 align:start position:0% money that the payee receives but due to 00:17:50.100 --> 00:17:51.830 align:start position:0% money that the payee receives but due to processing<00:17:50.610> delays<00:17:50.880> it's<00:17:51.240> still<00:17:51.480> accounted 00:17:51.830 --> 00:17:51.840 align:start position:0% processing delays it's still accounted 00:17:51.840 --> 00:17:53.870 align:start position:0% processing delays it's still accounted for<00:17:51.870> both<00:17:52.380> recipient<00:17:53.040> and<00:17:53.160> sender<00:17:53.460> balances 00:17:53.870 --> 00:17:53.880 align:start position:0% for both recipient and sender balances 00:17:53.880 --> 00:17:56.090 align:start position:0% for both recipient and sender balances and<00:17:54.090> as<00:17:55.020> a<00:17:55.049> recipient<00:17:55.440> receives<00:17:55.679> winning 00:17:56.090 --> 00:17:56.100 align:start position:0% and as a recipient receives winning 00:17:56.100 --> 00:17:58.039 align:start position:0% and as a recipient receives winning ticket<00:17:56.370> it's<00:17:56.610> gonna<00:17:56.820> increase<00:17:57.390> its<00:17:57.630> flow<00:17:57.809> as 00:17:58.039 --> 00:17:58.049 align:start position:0% ticket it's gonna increase its flow as 00:17:58.049 --> 00:18:00.500 align:start position:0% ticket it's gonna increase its flow as it<00:17:58.320> observes<00:17:59.160> on<00:17:59.460> chain<00:17:59.760> successful 00:18:00.500 --> 00:18:00.510 align:start position:0% it observes on chain successful 00:18:00.510 --> 00:18:01.100 align:start position:0% it observes on chain successful redemptions 00:18:01.100 --> 00:18:01.110 align:start position:0% redemptions 00:18:01.110 --> 00:18:03.320 align:start position:0% redemptions is<00:18:01.200> going<00:18:01.500> to<00:18:01.620> decrease<00:18:01.950> the<00:18:02.160> flow<00:18:02.220> and<00:18:02.669> the 00:18:03.320 --> 00:18:03.330 align:start position:0% is going to decrease the flow and the 00:18:03.330 --> 00:18:04.640 align:start position:0% is going to decrease the flow and the max<00:18:03.540> flow<00:18:03.720> is<00:18:03.900> essentially<00:18:04.230> the<00:18:04.410> reserve 00:18:04.640 --> 00:18:04.650 align:start position:0% max flow is essentially the reserve 00:18:04.650 --> 00:18:06.470 align:start position:0% max flow is essentially the reserve allocation<00:18:05.190> that<00:18:05.370> you<00:18:05.429> provide<00:18:05.820> a<00:18:06.090> recipient 00:18:06.470 --> 00:18:06.480 align:start position:0% allocation that you provide a recipient 00:18:06.480 --> 00:18:08.060 align:start position:0% allocation that you provide a recipient from<00:18:06.900> the<00:18:06.990> reserve<00:18:07.290> you've<00:18:07.470> defined<00:18:07.770> the<00:18:07.890> MA 00:18:08.060 --> 00:18:08.070 align:start position:0% from the reserve you've defined the MA 00:18:08.070 --> 00:18:11.299 align:start position:0% from the reserve you've defined the MA chain<00:18:08.750> so<00:18:09.750> I'm<00:18:09.929> just<00:18:10.110> through<00:18:10.530> this<00:18:10.710> but<00:18:11.100> this 00:18:11.299 --> 00:18:11.309 align:start position:0% chain so I'm just through this but this 00:18:11.309 --> 00:18:13.430 align:start position:0% chain so I'm just through this but this basically<00:18:11.700> demonstrates<00:18:12.299> the<00:18:12.510> simplest<00:18:13.260> flow 00:18:13.430 --> 00:18:13.440 align:start position:0% basically demonstrates the simplest flow 00:18:13.440 --> 00:18:15.060 align:start position:0% basically demonstrates the simplest flow with<00:18:13.860> a<00:18:14.100> single<00:18:14.400> reserve 00:18:15.060 --> 00:18:15.070 align:start position:0% with a single reserve 00:18:15.070 --> 00:18:17.580 align:start position:0% with a single reserve to<00:18:15.160> a<00:18:15.190> similar<00:18:15.490> recipient<00:18:16.320> but<00:18:17.320> the<00:18:17.440> last 00:18:17.580 --> 00:18:17.590 align:start position:0% to a similar recipient but the last 00:18:17.590 --> 00:18:19.290 align:start position:0% to a similar recipient but the last question<00:18:17.920> we<00:18:18.070> need<00:18:18.160> to<00:18:18.220> solve<00:18:18.490> is<00:18:18.880> how<00:18:19.180> do<00:18:19.240> you 00:18:19.290 --> 00:18:19.300 align:start position:0% question we need to solve is how do you 00:18:19.300 --> 00:18:20.820 align:start position:0% question we need to solve is how do you actually<00:18:19.420> bound<00:18:19.750> the<00:18:19.930> ability<00:18:20.350> from<00:18:20.500> double 00:18:20.820 --> 00:18:20.830 align:start position:0% actually bound the ability from double 00:18:20.830 --> 00:18:23.280 align:start position:0% actually bound the ability from double spending<00:18:21.130> so<00:18:21.520> the<00:18:22.330> way<00:18:22.480> that<00:18:22.510> we<00:18:22.750> do<00:18:22.870> this<00:18:23.020> is 00:18:23.280 --> 00:18:23.290 align:start position:0% spending so the way that we do this is 00:18:23.290 --> 00:18:24.720 align:start position:0% spending so the way that we do this is that<00:18:23.440> we<00:18:23.500> commit<00:18:23.920> each<00:18:24.100> Reserve<00:18:24.430> to<00:18:24.700> a 00:18:24.720 --> 00:18:24.730 align:start position:0% that we commit each Reserve to a 00:18:24.730 --> 00:18:27.690 align:start position:0% that we commit each Reserve to a well-defined<00:18:25.300> recipient<00:18:25.870> set<00:18:26.050> and<00:18:26.400> in<00:18:27.400> the 00:18:27.690 --> 00:18:27.700 align:start position:0% well-defined recipient set and in the 00:18:27.700 --> 00:18:29.070 align:start position:0% well-defined recipient set and in the light<00:18:27.850> of<00:18:27.880> your<00:18:28.060> protocol<00:18:28.450> we<00:18:28.630> can<00:18:28.810> actually 00:18:29.070 --> 00:18:29.080 align:start position:0% light of your protocol we can actually 00:18:29.080 --> 00:18:30.810 align:start position:0% light of your protocol we can actually take<00:18:29.230> advantage<00:18:29.260> of<00:18:29.830> an<00:18:29.980> existing<00:18:30.430> provider 00:18:30.810 --> 00:18:30.820 align:start position:0% take advantage of an existing provider 00:18:30.820 --> 00:18:33.750 align:start position:0% take advantage of an existing provider set<00:18:31.090> rotation<00:18:31.240> process<00:18:31.930> so<00:18:32.500> each<00:18:33.040> round<00:18:33.400> or 00:18:33.750 --> 00:18:33.760 align:start position:0% set rotation process so each round or 00:18:33.760 --> 00:18:36.060 align:start position:0% set rotation process so each round or time<00:18:34.120> we<00:18:34.420> talk<00:18:34.630> we<00:18:35.020> have<00:18:35.200> a<00:18:35.410> specific<00:18:35.620> set<00:18:35.950> of 00:18:36.060 --> 00:18:36.070 align:start position:0% time we talk we have a specific set of 00:18:36.070 --> 00:18:38.040 align:start position:0% time we talk we have a specific set of providers<00:18:36.340> and<00:18:36.760> we<00:18:37.120> just<00:18:37.300> commit<00:18:37.600> the<00:18:37.750> reserve 00:18:38.040 --> 00:18:38.050 align:start position:0% providers and we just commit the reserve 00:18:38.050 --> 00:18:40.350 align:start position:0% providers and we just commit the reserve to<00:18:38.290> that<00:18:38.470> particular<00:18:39.280> set<00:18:39.520> of<00:18:39.700> providers<00:18:39.970> and 00:18:40.350 --> 00:18:40.360 align:start position:0% to that particular set of providers and 00:18:40.360 --> 00:18:42.180 align:start position:0% to that particular set of providers and then<00:18:40.900> we<00:18:40.990> split<00:18:41.200> the<00:18:41.350> reserve<00:18:41.650> into<00:18:41.920> equal 00:18:42.180 --> 00:18:42.190 align:start position:0% then we split the reserve into equal 00:18:42.190 --> 00:18:43.770 align:start position:0% then we split the reserve into equal size<00:18:42.400> allocations<00:18:43.030> committed<00:18:43.570> to<00:18:43.660> each 00:18:43.770 --> 00:18:43.780 align:start position:0% size allocations committed to each 00:18:43.780 --> 00:18:45.810 align:start position:0% size allocations committed to each member<00:18:43.990> of<00:18:44.140> the<00:18:44.290> set<00:18:44.500> so<00:18:44.800> we<00:18:45.310> can<00:18:45.400> see<00:18:45.580> here 00:18:45.810 --> 00:18:45.820 align:start position:0% member of the set so we can see here 00:18:45.820 --> 00:18:47.490 align:start position:0% member of the set so we can see here that<00:18:46.060> in<00:18:46.240> round<00:18:46.420> one<00:18:46.630> we<00:18:46.930> split<00:18:47.170> it<00:18:47.260> three<00:18:47.470> ways 00:18:47.490 --> 00:18:47.500 align:start position:0% that in round one we split it three ways 00:18:47.500 --> 00:18:48.990 align:start position:0% that in round one we split it three ways because<00:18:47.920> there's<00:18:48.130> three<00:18:48.310> recipients<00:18:48.790> in 00:18:48.990 --> 00:18:49.000 align:start position:0% because there's three recipients in 00:18:49.000 --> 00:18:51.180 align:start position:0% because there's three recipients in round<00:18:49.600> two<00:18:49.810> we<00:18:50.140> have<00:18:50.260> new<00:18:50.410> recipients<00:18:50.890> so<00:18:51.070> we 00:18:51.180 --> 00:18:51.190 align:start position:0% round two we have new recipients so we 00:18:51.190 --> 00:18:53.790 align:start position:0% round two we have new recipients so we increase<00:18:51.640> the<00:18:51.940> we<00:18:52.720> decrease<00:18:53.110> the<00:18:53.140> allocation 00:18:53.790 --> 00:18:53.800 align:start position:0% increase the we decrease the allocation 00:18:53.800 --> 00:18:55.260 align:start position:0% increase the we decrease the allocation for<00:18:53.980> each<00:18:54.100> because<00:18:54.430> there's<00:18:54.640> more<00:18:54.790> recipients 00:18:55.260 --> 00:18:55.270 align:start position:0% for each because there's more recipients 00:18:55.270 --> 00:18:58.140 align:start position:0% for each because there's more recipients and<00:18:55.510> similarly<00:18:56.350> when<00:18:56.650> we<00:18:56.890> recipients<00:18:57.340> exit<00:18:57.700> we 00:18:58.140 --> 00:18:58.150 align:start position:0% and similarly when we recipients exit we 00:18:58.150 --> 00:18:59.670 align:start position:0% and similarly when we recipients exit we have<00:18:58.330> to<00:18:58.480> split<00:18:58.630> it<00:18:58.810> two<00:18:58.930> ways<00:18:59.080> because<00:18:59.500> now 00:18:59.670 --> 00:18:59.680 align:start position:0% have to split it two ways because now 00:18:59.680 --> 00:19:01.170 align:start position:0% have to split it two ways because now there's<00:18:59.920> two<00:19:00.100> recipients<00:19:00.640> instead<00:19:00.880> of<00:19:01.000> four 00:19:01.170 --> 00:19:01.180 align:start position:0% there's two recipients instead of four 00:19:01.180 --> 00:19:02.910 align:start position:0% there's two recipients instead of four and<00:19:01.690> that's<00:19:02.050> reflected<00:19:02.500> in<00:19:02.560> the<00:19:02.620> reserve 00:19:02.910 --> 00:19:02.920 align:start position:0% and that's reflected in the reserve 00:19:02.920 --> 00:19:04.260 align:start position:0% and that's reflected in the reserve allocation<00:19:03.460> that's<00:19:03.640> committed<00:19:04.030> to<00:19:04.060> each 00:19:04.260 --> 00:19:04.270 align:start position:0% allocation that's committed to each 00:19:04.270 --> 00:19:07.860 align:start position:0% allocation that's committed to each recipient<00:19:04.780> so<00:19:05.770> in<00:19:05.890> summary<00:19:06.420> this<00:19:07.420> helps<00:19:07.780> us 00:19:07.860 --> 00:19:07.870 align:start position:0% recipient so in summary this helps us 00:19:07.870 --> 00:19:09.990 align:start position:0% recipient so in summary this helps us avoid<00:19:08.140> additional<00:19:08.500> on<00:19:08.890> champions<00:19:09.310> actions<00:19:09.670> to 00:19:09.990 --> 00:19:10.000 align:start position:0% avoid additional on champions actions to 00:19:10.000 --> 00:19:12.450 align:start position:0% avoid additional on champions actions to update<00:19:10.480> recipients<00:19:11.320> a<00:19:11.440> commitment<00:19:11.860> some<00:19:12.370> of 00:19:12.450 --> 00:19:12.460 align:start position:0% update recipients a commitment some of 00:19:12.460 --> 00:19:14.130 align:start position:0% update recipients a commitment some of the<00:19:12.520> downsides<00:19:12.970> are<00:19:13.090> that<00:19:13.150> you<00:19:13.390> can't<00:19:13.630> update 00:19:14.130 --> 00:19:14.140 align:start position:0% the downsides are that you can't update 00:19:14.140 --> 00:19:15.570 align:start position:0% the downsides are that you can't update the<00:19:14.320> allocation<00:19:14.890> for<00:19:15.130> each<00:19:15.250> particular 00:19:15.570 --> 00:19:15.580 align:start position:0% the allocation for each particular 00:19:15.580 --> 00:19:17.460 align:start position:0% the allocation for each particular recipient<00:19:16.480> so<00:19:16.630> if<00:19:16.750> you<00:19:16.840> want<00:19:17.020> to<00:19:17.080> allocate 00:19:17.460 --> 00:19:17.470 align:start position:0% recipient so if you want to allocate 00:19:17.470 --> 00:19:18.960 align:start position:0% recipient so if you want to allocate more<00:19:17.680> it's<00:19:17.860> about<00:19:17.980> the<00:19:18.190> clitoris<00:19:18.370> again<00:19:18.790> you 00:19:18.960 --> 00:19:18.970 align:start position:0% more it's about the clitoris again you 00:19:18.970 --> 00:19:21.930 align:start position:0% more it's about the clitoris again you can<00:19:19.320> and<00:19:20.320> then<00:19:20.470> also<00:19:20.740> this<00:19:21.460> will<00:19:21.760> likely 00:19:21.930 --> 00:19:21.940 align:start position:0% can and then also this will likely 00:19:21.940 --> 00:19:23.970 align:start position:0% can and then also this will likely increase<00:19:22.390> the<00:19:22.570> reserve<00:19:22.870> requirement<00:19:23.470> overall 00:19:23.970 --> 00:19:23.980 align:start position:0% increase the reserve requirement overall 00:19:23.980 --> 00:19:25.680 align:start position:0% increase the reserve requirement overall as<00:19:24.250> the<00:19:24.520> number<00:19:24.760> of<00:19:24.820> recipients<00:19:25.210> increase 00:19:25.680 --> 00:19:25.690 align:start position:0% as the number of recipients increase 00:19:25.690 --> 00:19:28.460 align:start position:0% as the number of recipients increase because<00:19:26.400> some<00:19:27.400> recipients<00:19:27.850> might 00:19:28.460 --> 00:19:28.470 align:start position:0% because some recipients might 00:19:28.470 --> 00:19:31.170 align:start position:0% because some recipients might allocation<00:19:29.470> but<00:19:30.310> some<00:19:30.490> of<00:19:30.580> this<00:19:30.670> may<00:19:30.910> be<00:19:30.970> able 00:19:31.170 --> 00:19:31.180 align:start position:0% allocation but some of this may be able 00:19:31.180 --> 00:19:32.730 align:start position:0% allocation but some of this may be able to<00:19:31.330> be<00:19:31.450> solved<00:19:31.840> with<00:19:32.080> alternate 00:19:32.730 --> 00:19:32.740 align:start position:0% to be solved with alternate 00:19:32.740 --> 00:19:34.770 align:start position:0% to be solved with alternate constructions<00:19:33.280> that<00:19:33.460> and<00:19:34.360> probably<00:19:34.630> talk 00:19:34.770 --> 00:19:34.780 align:start position:0% constructions that and probably talk 00:19:34.780 --> 00:19:37.440 align:start position:0% constructions that and probably talk about<00:19:34.990> after<00:19:35.320> the<00:19:35.440> presentation<00:19:35.980> and<00:19:36.550> with 00:19:37.440 --> 00:19:37.450 align:start position:0% about after the presentation and with 00:19:37.450 --> 00:19:38.790 align:start position:0% about after the presentation and with that<00:19:37.600> I'm<00:19:37.870> going<00:19:38.020> to<00:19:38.050> pass<00:19:38.200> it<00:19:38.350> back<00:19:38.380> over<00:19:38.650> to 00:19:38.790 --> 00:19:38.800 align:start position:0% that I'm going to pass it back over to 00:19:38.800 --> 00:19:41.220 align:start position:0% that I'm going to pass it back over to Doug<00:19:39.040> to<00:19:39.310> talk<00:19:39.520> about<00:19:39.700> network<00:19:40.690> sense<00:19:40.960> and 00:19:41.220 --> 00:19:41.230 align:start position:0% Doug to talk about network sense and 00:19:41.230 --> 00:19:44.060 align:start position:0% Doug to talk about network sense and there<00:19:41.410> was<00:19:41.500> a<00:19:41.560> source<00:19:41.800> of<00:19:41.890> indecision 00:19:44.060 --> 00:19:44.070 align:start position:0% there was a source of indecision 00:19:44.070 --> 00:19:46.230 align:start position:0% there was a source of indecision thanks<00:19:45.070> John<00:19:45.220> and<00:19:45.250> say<00:19:45.520> I'll<00:19:45.640> just<00:19:45.790> wrap<00:19:45.970> up<00:19:46.090> in 00:19:46.230 --> 00:19:46.240 align:start position:0% thanks John and say I'll just wrap up in 00:19:46.240 --> 00:19:49.740 align:start position:0% thanks John and say I'll just wrap up in the<00:19:46.330> last<00:19:46.510> minute<00:19:47.610> as<00:19:48.610> I<00:19:48.790> mentioned<00:19:49.180> my<00:19:49.480> peers 00:19:49.740 --> 00:19:49.750 align:start position:0% the last minute as I mentioned my peers 00:19:49.750 --> 00:19:51.690 align:start position:0% the last minute as I mentioned my peers p2p<00:19:50.170> live-streaming<00:19:50.770> infrastructure<00:19:51.490> and<00:19:51.610> so 00:19:51.690 --> 00:19:51.700 align:start position:0% p2p live-streaming infrastructure and so 00:19:51.700 --> 00:19:53.700 align:start position:0% p2p live-streaming infrastructure and so we<00:19:51.820> use<00:19:52.000> these<00:19:52.180> micro<00:19:52.510> payments<00:19:52.930> to<00:19:53.110> send<00:19:53.380> to 00:19:53.700 --> 00:19:53.710 align:start position:0% we use these micro payments to send to 00:19:53.710 --> 00:19:55.260 align:start position:0% we use these micro payments to send to infrastructure<00:19:54.250> operators<00:19:54.580> on<00:19:54.880> the<00:19:54.940> network 00:19:55.260 --> 00:19:55.270 align:start position:0% infrastructure operators on the network 00:19:55.270 --> 00:20:00.330 align:start position:0% infrastructure operators on the network coding<00:19:56.050> video<00:19:56.290> and<00:19:57.510> running<00:19:58.510> on<00:19:58.900> the<00:19:59.440> you<00:20:00.250> know 00:20:00.330 --> 00:20:00.340 align:start position:0% coding video and running on the you know 00:20:00.340 --> 00:20:01.800 align:start position:0% coding video and running on the you know we've<00:20:00.490> been<00:20:00.580> violent<00:20:01.180> in<00:20:01.270> debt<00:20:01.480> with<00:20:01.600> NASA 00:20:01.800 --> 00:20:01.810 align:start position:0% we've been violent in debt with NASA 00:20:01.810 --> 00:20:03.540 align:start position:0% we've been violent in debt with NASA that<00:20:02.110> doesn't<00:20:02.410> use<00:20:02.530> this<00:20:02.680> mechanic<00:20:03.370> we've 00:20:03.540 --> 00:20:03.550 align:start position:0% that doesn't use this mechanic we've 00:20:03.550 --> 00:20:04.920 align:start position:0% that doesn't use this mechanic we've been<00:20:03.670> using<00:20:03.850> this<00:20:04.000> mechanic<00:20:04.420> intestines 00:20:04.920 --> 00:20:04.930 align:start position:0% been using this mechanic intestines 00:20:04.930 --> 00:20:06.780 align:start position:0% been using this mechanic intestines about<00:20:05.200> to<00:20:05.320> go<00:20:05.410> a<00:20:05.440> lot<00:20:05.590> of<00:20:05.710> short<00:20:05.950> they<00:20:06.160> I<00:20:06.400> bet 00:20:06.780 --> 00:20:06.790 align:start position:0% about to go a lot of short they I bet 00:20:06.790 --> 00:20:07.890 align:start position:0% about to go a lot of short they I bet you're<00:20:06.910> some<00:20:07.060> graphs<00:20:07.270> from<00:20:07.390> our<00:20:07.540> tests<00:20:07.810> that 00:20:07.890 --> 00:20:07.900 align:start position:0% you're some graphs from our tests that 00:20:07.900 --> 00:20:10.050 align:start position:0% you're some graphs from our tests that that<00:20:08.230> it's<00:20:08.830> a<00:20:08.860> little<00:20:09.070> small<00:20:09.280> but<00:20:09.310> basically 00:20:10.050 --> 00:20:10.060 align:start position:0% that it's a little small but basically 00:20:10.060 --> 00:20:11.220 align:start position:0% that it's a little small but basically everything's<00:20:10.570> going<00:20:10.810> up<00:20:10.900> into<00:20:11.050> the<00:20:11.140> right 00:20:11.220 --> 00:20:11.230 align:start position:0% everything's going up into the right 00:20:11.230 --> 00:20:13.620 align:start position:0% everything's going up into the right which<00:20:11.590> is<00:20:11.740> usually<00:20:12.070> good<00:20:12.280> there's<00:20:13.270> no<00:20:13.360> number 00:20:13.620 --> 00:20:13.630 align:start position:0% which is usually good there's no number 00:20:13.630 --> 00:20:16.110 align:start position:0% which is usually good there's no number two<00:20:13.870> it's<00:20:14.050> N<00:20:14.320> and<00:20:14.530> belly<00:20:14.710> cent<00:20:15.250> increase<00:20:15.730> in 00:20:16.110 --> 00:20:16.120 align:start position:0% two it's N and belly cent increase in 00:20:16.120 --> 00:20:18.570 align:start position:0% two it's N and belly cent increase in tickets<00:20:16.420> redeemed<00:20:16.810> and<00:20:17.290> value<00:20:17.980> indeed 00:20:18.570 --> 00:20:18.580 align:start position:0% tickets redeemed and value indeed 00:20:18.580 --> 00:20:20.760 align:start position:0% tickets redeemed and value indeed received<00:20:19.180> increasing<00:20:19.840> and<00:20:20.140> then<00:20:20.560> in<00:20:20.680> the 00:20:20.760 --> 00:20:20.770 align:start position:0% received increasing and then in the 00:20:20.770 --> 00:20:21.960 align:start position:0% received increasing and then in the yellow 00:20:21.960 --> 00:20:21.970 align:start position:0% yellow 00:20:21.970 --> 00:20:24.300 align:start position:0% yellow it's<00:20:22.330> kind<00:20:22.630> of<00:20:22.690> winning<00:20:22.990> tickets<00:20:23.380> and<00:20:23.590> valuing 00:20:24.300 --> 00:20:24.310 align:start position:0% it's kind of winning tickets and valuing 00:20:24.310 --> 00:20:26.160 align:start position:0% it's kind of winning tickets and valuing team<00:20:24.460> gone<00:20:24.700> chain<00:20:25.000> and<00:20:25.300> the<00:20:25.690> kind<00:20:25.870> of<00:20:25.900> the<00:20:25.990> key 00:20:26.160 --> 00:20:26.170 align:start position:0% team gone chain and the kind of the key 00:20:26.170 --> 00:20:28.050 align:start position:0% team gone chain and the kind of the key takeaway<00:20:26.560> to<00:20:26.620> the<00:20:26.770> key<00:20:26.890> benchmark<00:20:27.370> is<00:20:27.580> that 00:20:28.050 --> 00:20:28.060 align:start position:0% takeaway to the key benchmark is that 00:20:28.060 --> 00:20:31.110 align:start position:0% takeaway to the key benchmark is that we've<00:20:28.690> fluctuated<00:20:29.410> gas<00:20:29.620> prices<00:20:30.160> in 00:20:31.110 --> 00:20:31.120 align:start position:0% we've fluctuated gas prices in 00:20:31.120 --> 00:20:32.640 align:start position:0% we've fluctuated gas prices in simulation<00:20:31.720> to<00:20:31.840> how<00:20:31.930> they<00:20:32.050> fluctuate<00:20:32.290> is<00:20:32.590> a 00:20:32.640 --> 00:20:32.650 align:start position:0% simulation to how they fluctuate is a 00:20:32.650 --> 00:20:34.820 align:start position:0% simulation to how they fluctuate is a maintenance<00:20:33.130> and<00:20:33.370> we've<00:20:33.790> observed<00:20:34.150> that<00:20:34.420> the 00:20:34.820 --> 00:20:34.830 align:start position:0% maintenance and we've observed that the 00:20:34.830 --> 00:20:36.630 align:start position:0% maintenance and we've observed that the recipients<00:20:35.830> you<00:20:36.040> know<00:20:36.130> the<00:20:36.220> software<00:20:36.550> will 00:20:36.630 --> 00:20:36.640 align:start position:0% recipients you know the software will 00:20:36.640 --> 00:20:37.920 align:start position:0% recipients you know the software will automatically<00:20:37.210> update<00:20:37.360> their<00:20:37.660> ticket 00:20:37.920 --> 00:20:37.930 align:start position:0% automatically update their ticket 00:20:37.930 --> 00:20:39.750 align:start position:0% automatically update their ticket parameters<00:20:38.410> to<00:20:38.950> ensure<00:20:39.130> that<00:20:39.190> wherever<00:20:39.460> gas 00:20:39.750 --> 00:20:39.760 align:start position:0% parameters to ensure that wherever gas 00:20:39.760 --> 00:20:40.740 align:start position:0% parameters to ensure that wherever gas prices<00:20:40.240> go 00:20:40.740 --> 00:20:40.750 align:start position:0% prices go 00:20:40.750 --> 00:20:43.620 align:start position:0% prices go they<00:20:40.990> never<00:20:41.200> have<00:20:41.440> more<00:20:41.680> than<00:20:41.890> one<00:20:42.730> of<00:20:42.790> the<00:20:42.880> 1% 00:20:43.620 --> 00:20:43.630 align:start position:0% they never have more than one of the 1% 00:20:43.630 --> 00:20:46.189 align:start position:0% they never have more than one of the 1% overhead<00:20:44.410> for<00:20:44.980> cashing<00:20:45.430> in<00:20:45.520> on<00:20:45.610> chance 00:20:46.189 --> 00:20:46.199 align:start position:0% overhead for cashing in on chance 00:20:46.199 --> 00:20:48.689 align:start position:0% overhead for cashing in on chance $3,100<00:20:47.229> and<00:20:47.589> everything<00:20:47.889> more<00:20:48.039> than<00:20:48.099> $1<00:20:48.459> in 00:20:48.689 --> 00:20:48.699 align:start position:0% $3,100 and everything more than $1 in 00:20:48.699 --> 00:20:50.899 align:start position:0% $3,100 and everything more than $1 in order<00:20:48.939> to<00:20:49.059> cash<00:20:49.269> the<00:20:50.169> tickets<00:20:50.409> a<00:20:50.499> knot<00:20:50.619> chin 00:20:50.899 --> 00:20:50.909 align:start position:0% order to cash the tickets a knot chin 00:20:50.909 --> 00:20:53.459 align:start position:0% order to cash the tickets a knot chin and<00:20:51.909> that's<00:20:52.179> just<00:20:52.449> a<00:20:52.509> target<00:20:52.719> that<00:20:53.049> we<00:20:53.169> picked 00:20:53.459 --> 00:20:53.469 align:start position:0% and that's just a target that we picked 00:20:53.469 --> 00:20:55.339 align:start position:0% and that's just a target that we picked but<00:20:53.739> we<00:20:53.829> think<00:20:53.949> that<00:20:54.069> that's<00:20:54.219> acceptable 00:20:55.339 --> 00:20:55.349 align:start position:0% but we think that that's acceptable 00:20:55.349 --> 00:20:57.599 align:start position:0% but we think that that's acceptable relative<00:20:56.349> to<00:20:56.559> a<00:20:56.589> kind<00:20:56.979> of<00:20:57.039> traditional 00:20:57.599 --> 00:20:57.609 align:start position:0% relative to a kind of traditional 00:20:57.609 --> 00:20:59.759 align:start position:0% relative to a kind of traditional mechanics<00:20:58.389> in<00:20:58.479> the<00:20:58.539> blockchain<00:20:58.749> so<00:20:59.199> working 00:20:59.759 --> 00:20:59.769 align:start position:0% mechanics in the blockchain so working 00:20:59.769 --> 00:21:03.259 align:start position:0% mechanics in the blockchain so working well<00:21:00.069> yeah<00:21:00.729> open-source<00:21:01.469> implementation 00:21:03.259 --> 00:21:03.269 align:start position:0% well yeah open-source implementation 00:21:03.269 --> 00:21:07.199 align:start position:0% well yeah open-source implementation will<00:21:04.269> share<00:21:04.569> these<00:21:04.689> links<00:21:04.899> out<00:21:05.759> on<00:21:06.759> Twitter 00:21:07.199 --> 00:21:07.209 align:start position:0% will share these links out on Twitter 00:21:07.209 --> 00:21:10.079 align:start position:0% will share these links out on Twitter after<00:21:08.079> the<00:21:08.199> talk<00:21:08.439> black<00:21:09.129> beard<00:21:09.309> or<00:21:09.579> go<00:21:09.879> get<00:21:10.029> a 00:21:10.079 --> 00:21:10.089 align:start position:0% after the talk black beard or go get a 00:21:10.089 --> 00:21:12.239 align:start position:0% after the talk black beard or go get a specification<00:21:10.829> smart<00:21:11.829> contract 00:21:12.239 --> 00:21:12.249 align:start position:0% specification smart contract 00:21:12.249 --> 00:21:14.429 align:start position:0% specification smart contract implementation<00:21:12.909> solidity<00:21:13.389> and<00:21:13.689> client 00:21:14.429 --> 00:21:14.439 align:start position:0% implementation solidity and client 00:21:14.439 --> 00:21:18.719 align:start position:0% implementation solidity and client implementation<00:21:14.979> in<00:21:15.129> go<00:21:15.249> length<00:21:16.229> this<00:21:17.229> is<00:21:17.729> able 00:21:18.719 --> 00:21:18.729 align:start position:0% implementation in go length this is able 00:21:18.729 --> 00:21:21.179 align:start position:0% implementation in go length this is able to<00:21:18.879> be<00:21:18.999> used<00:21:19.319> for<00:21:20.319> general<00:21:20.619> use<00:21:20.889> their<00:21:21.039> cross 00:21:21.179 --> 00:21:21.189 align:start position:0% to be used for general use their cross 00:21:21.189 --> 00:21:23.159 align:start position:0% to be used for general use their cross program<00:21:21.549> projects<00:21:22.119> in<00:21:22.179> the<00:21:22.239> ecosystem<00:21:22.779> it 00:21:23.159 --> 00:21:23.169 align:start position:0% program projects in the ecosystem it 00:21:23.169 --> 00:21:25.349 align:start position:0% program projects in the ecosystem it means<00:21:23.349> a<00:21:23.469> little<00:21:23.739> bit<00:21:24.069> of<00:21:24.189> work<00:21:24.429> to<00:21:24.639> separate 00:21:25.349 --> 00:21:25.359 align:start position:0% means a little bit of work to separate 00:21:25.359 --> 00:21:27.799 align:start position:0% means a little bit of work to separate out<00:21:25.479> some<00:21:25.689> of<00:21:25.839> the<00:21:25.989> library<00:21:26.349> specific 00:21:27.799 --> 00:21:27.809 align:start position:0% out some of the library specific 00:21:27.809 --> 00:21:30.119 align:start position:0% out some of the library specific implementation<00:21:28.809> details<00:21:29.259> around<00:21:29.859> these 00:21:30.119 --> 00:21:30.129 align:start position:0% implementation details around these 00:21:30.129 --> 00:21:32.609 align:start position:0% implementation details around these global<00:21:30.489> recipients<00:21:30.969> assumptions<00:21:31.809> but<00:21:32.469> it's 00:21:32.609 --> 00:21:32.619 align:start position:0% global recipients assumptions but it's 00:21:32.619 --> 00:21:33.989 align:start position:0% global recipients assumptions but it's not<00:21:32.739> far<00:21:32.949> off<00:21:32.979> surrounded<00:21:33.579> to<00:21:33.639> collaborate 00:21:33.989 --> 00:21:33.999 align:start position:0% not far off surrounded to collaborate 00:21:33.999 --> 00:21:35.909 align:start position:0% not far off surrounded to collaborate with<00:21:34.029> people<00:21:34.209> who<00:21:34.359> want<00:21:34.539> to<00:21:34.569> use<00:21:34.629> this<00:21:34.929> make 00:21:35.909 --> 00:21:35.919 align:start position:0% with people who want to use this make 00:21:35.919 --> 00:21:37.769 align:start position:0% with people who want to use this make development<00:21:36.369> for<00:21:36.459> the<00:21:36.519> whole<00:21:36.639> ecosystem<00:21:36.849> so 00:21:37.769 --> 00:21:37.779 align:start position:0% development for the whole ecosystem so 00:21:37.779 --> 00:21:40.529 align:start position:0% development for the whole ecosystem so thank<00:21:38.289> you<00:21:38.409> very<00:21:38.439> much<00:21:38.889> for<00:21:39.819> attending<00:21:40.119> the 00:21:40.529 --> 00:21:40.539 align:start position:0% thank you very much for attending the 00:21:40.539 --> 00:21:43.529 align:start position:0% thank you very much for attending the talk<00:21:40.749> I<00:21:41.139> said<00:21:41.799> live<00:21:42.129> here<00:21:42.339> dot<00:21:42.549> work<00:21:42.819> and<00:21:43.329> we're 00:21:43.529 --> 00:21:43.539 align:start position:0% talk I said live here dot work and we're 00:21:43.539 --> 00:21:48.570 align:start position:0% talk I said live here dot work and we're around<00:21:43.659> the<00:21:43.809> conference<00:21:43.989> all<00:21:44.319> week 00:21:48.570 --> 00:21:48.580 align:start position:0% 00:21:48.580 --> 00:21:55.030 align:start position:0% [Applause]