Replay

replay

Authors:
(1) Sebastian Dziadzio, University of Tübingen (sebastian.dziadzio@uni-tuebingen.de);
(2) Çagatay Yıldız, University of Tübingen;
(3) Gido M. van de Ven, KU Leuven;
(4) Tomasz Trzcinski, IDEAS NCBR, Warsaw University of Technology, Tooploox;
(5) Tinne Tuytelaars, KU Leuven;
(6) Matthias Bethge, University of Tübingen. Table of Links Abstract and 1. Introduction 2. Two problems with the current approach to class-incremental continual learning 3. Methods and 3.1. Infinite dSprites 3.2. Disentangled learning 4. Related work 4.1. Continual learning and 4.2. Benchmarking continual learning 5. Experiments 5.1. Regularization methods and 5.2. Replay-based methods 5.3. Do we need equivariance? 5.4. One-shot generalization and 5.5. Open-set classification 5.6. Online vs. offline Conclusion, Acknowledgments and References Supplementary Material 5.1. Regularization methods In this section, we compare our method to standard regularization methods: Learning without Forgetting (LwF) [17] and Synaptic Intelligence (SI) [39]. We use implementations from Avalanche [21]. We provide details of the hyperparameter choice in the supplementary material. As shown in Fig. 4, such regularization methods are ill-equipped to deal with the class-incremental learning scenario and perform no better than naive fine-tuning. 5.2. Replay-based methods Replay-based methods retain a subset of past training data that is then mixed with the current training data for every task. While this can be a viable strategy to preserve accuracy over many tasks, it results in ever-growing memory and computation requirements, unless the buffer size is bounded. In this section, we investigate the effect of buffer size on performance for standard experience replay with reservoir sampling. While there are replay-based methods that improve on this baseline, we are interested in investigating the fundamental limits of rehearsal over long time horizons and strip away the confounding effects of data augmentation, generative replay, sampling strategies, pseudo-rehearsal etc. Figure 5 shows test accuracy for experience replay with different buffer sizes. Storing enough past samples lets the model maintain high test accuracy, but even with a buffer of 20,000 images the performance eventually starts to deteriorate. Note that after 200 tasks a balanced buffer will only contain 10 samples per class. A note on implementation In an attempt to make the replay baseline stronger, we first add the data from the current task to the buffer and then train the model exclusively on the buffer, effectively discounting the influence of the current task over time [28]. A more standard version of experience replay would mix current and past data in equal proportions in each mini-batch, likely leading to diminished performance on previous tasks. The supplementary material includes a comparison to this other replay baseline, as well as to a version of experience replay with no memory constraint but with a compute budget matching our approach. This paper is available on arxiv under CC 4.0 license. Authors: (1) Sebastian Dziadzio, University of Tübingen (sebastian.dziadzio@uni-tuebingen.de); (2) Çagatay Yıldız, University of Tübingen; (3) Gido M. van de Ven, KU Leuven; (4) Tomasz Trzcinski, IDEAS NCBR, Warsaw University of Technology, Tooploox; (5) Tinne Tuytelaars, KU Leuven; (6) Matthias Bethge, University of Tübingen. Authors: Authors: (1) Sebastian Dziadzio, University of Tübingen (sebastian.dziadzio@uni-tuebingen.de); (2) Çagatay Yıldız, University of Tübingen; (3) Gido M. van de Ven, KU Leuven; (4) Tomasz Trzcinski, IDEAS NCBR, Warsaw University of Technology, Tooploox; (5) Tinne Tuytelaars, KU Leuven; (6) Matthias Bethge, University of Tübingen. Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2. Two problems with the current approach to class-incremental continual learning 2. Two problems with the current approach to class-incremental continual learning 3. Methods and 3.1. Infinite dSprites 3. Methods and 3.1. Infinite dSprites 3.2. Disentangled learning 3.2. Disentangled learning 4. Related work 4.1. Continual learning and 4.2. Benchmarking continual learning 4.1. Continual learning and 4.2. Benchmarking continual learning 5. Experiments 5. Experiments 5.1. Regularization methods and 5.2. Replay-based methods 5.1. Regularization methods and 5.2. Replay-based methods 5.3. Do we need equivariance? 5.3. Do we need equivariance? 5.4. One-shot generalization and 5.5. Open-set classification 5.4. One-shot generalization and 5.5. Open-set classification 5.6. Online vs. offline 5.6. Online vs. offline Conclusion, Acknowledgments and References Conclusion, Acknowledgments and References Supplementary Material Supplementary Material 5.1. Regularization methods In this section, we compare our method to standard regularization methods: Learning without Forgetting (LwF) [17] and Synaptic Intelligence (SI) [39]. We use implementations from Avalanche [21]. We provide details of the hyperparameter choice in the supplementary material. As shown in Fig. 4, such regularization methods are ill-equipped to deal with the class-incremental learning scenario and perform no better than naive fine-tuning. 5.2. Replay-based methods Replay-based methods retain a subset of past training data that is then mixed with the current training data for every task. While this can be a viable strategy to preserve accuracy over many tasks, it results in ever-growing memory and computation requirements, unless the buffer size is bounded. In this section, we investigate the effect of buffer size on performance for standard experience replay with reservoir sampling. While there are replay-based methods that improve on this baseline, we are interested in investigating the fundamental limits of rehearsal over long time horizons and strip away the confounding effects of data augmentation, generative replay, sampling strategies, pseudo-rehearsal etc. Figure 5 shows test accuracy for experience replay with different buffer sizes. Storing enough past samples lets the model maintain high test accuracy, but even with a buffer of 20,000 images the performance eventually starts to deteriorate. Note that after 200 tasks a balanced buffer will only contain 10 samples per class. A note on implementation In an attempt to make the replay baseline stronger, we first add the data from the current task to the buffer and then train the model exclusively on the A note on implementation buffer, effectively discounting the influence of the current task over time [28]. A more standard version of experience replay would mix current and past data in equal proportions in each mini-batch, likely leading to diminished performance on previous tasks. The supplementary material includes a comparison to this other replay baseline, as well as to a version of experience replay with no memory constraint but with a compute budget matching our approach. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

How Effective Are Standard Regularization and Replay Methods for Class-Incremental Learning? 

The Rise of Blockchain-based Video Streaming: Exclusive Interview With Replay CEO Michael Jelen

Event-driven architecture (EDA) is a software design pattern that emphasizes the production, detection, consumption, and reaction to events that occur within a system or across multiple systems. It is a style of architecture where the flow of data and the triggering of actions are driven by events. offers several benefits like higher scalability, modularity, and resilience due to the loosely coupled services compared to Request-Driven Architecture. Event-driven architecture However, it introduces some unique testing and monitoring challenges compared to traditional architectures: Events in an event-driven architecture may be processed asynchronously and can arrive out of order, and might be lost or duplicated. Testing and monitoring should include scenarios to validate how the system handles these situations. Event Ordering and Consistency: In event-driven systems, workflows are often driven by events. Coordinating the behavior of different services, validating event propagation, and ensuring correct data transformation across different workflows make End-to-End and Integration Testing much harder. Event-driven Workflow Validation: Events may evolve over time, with changes to their payload structure or schema, making it hard to ensure the compatibility of events across different versions. Event Payload and Schema Evolution: Event-driven architectures often involve services that are triggered by specific events. Generating and managing event simulations can be challenging, especially when dealing with a large number of events and complex workflows. Testing Event-Triggered Services: A great way to test these Event-driven systems is to use a record-replay strategy. Recording and replaying events allows you to capture real or simulated events and later replay them during testing to verify the behavior and correctness of the system. Here’s an overview of the steps involved in recording and replaying events: : Identify the events that need to be recorded for testing purposes. These can be actual events from a live system or simulated events generated specifically for testing and involves setting up a mechanism to capture and store the events in a suitable format for retrieval. This can be achieved by creating a dummy consumer for the topic we want to replay, which can store events in persistent storage like DB. Event Recording import kafka

# yield events from start_time to end_time

def record_events(self, start_time, end_time):
  consumer = kafka.KafkaConsumer(**(self._configs))
  
  #find offset for each partition which is just after start time
  
  seek_points = find_seek_points(start_time)
     
        try:
            # Set up a the consumer to fetch all desired partitions from their seek points
            
            for tp, offset in six.iteritems(seek_points):
                consumer.seek(tp, offset)
            
            while len(partitions) > 0:
                record = next(consumer)
                if not record:
                    partitions = set()
                else:
                    last_timestamp = record.timestamp
                    if last_timestamp > end_time:
                        partitions.discard(record.partition)
                        tp = kafka.TopicPartition(topic=record.topic, partition=record.partition)
                        if tp not in consumer.paused():
                            consumer.pause(tp)
                    elif (record.partition in partitions and last_timestamp >= start_time
                          and last_timestamp <= end_time):
                        # Send the record to the client if it's within the specified time range
                        yield record Source: https://github.com/SiftScience/python-kafka-replayer : Set up the test environment with a message queue and services configured. Add a dummy producer which reads the events from DB and adds them to the queue. Event Replaying from kafka import KafkaProducer

#read events from DB
events = recordedEvents.stream()

#send next event 
def generate_message():
    return events.next()

# Kafka Producer
producer = KafkaProducer(
    bootstrap_servers=['localhost:9092']
)
if __name__ == '__main__':
    # Infinite loop - runs until you kill the program
    while True:
        recorded_event = generate_message()     
        producer.send('messages', dummy_message) You can extend this simple setup by — adding delays, event duplication, and data corruption to analyze the system’s performance, resilience, and behavior under different event scenarios. By recording and replaying events, you can simulate real-world scenarios, edge cases, or failure conditions, providing a comprehensive testing approach for event-driven architecture. It helps uncover bugs, validate event processing, and ensure the system functions as intended when exposed to various event sequences and scenarios. Also published here.

Record-Replay Strategy for Testing Event-Driven Architecture

1 Auto Recording Amazon IVS Live Streams to S3 2 Archiving Web Chat Messages with Amazon IVS Chat Logging 3 Amazon IVS Live Stream Playback with Chat Replay In our last few posts, we've looked at how to auto-record Amazon Interactive Video Service (Amazon IVS) live streams to Amazon S3, and how to log messages sent to an Amazon IVS chat room (see links above). In this post, we'll bring these two concepts together to complete the user experience and create on-demand playback of past live streams with full chat replay. As seen in our last post, chat messages that are logged to the logging destination include a GMT based timestamp representing the date and time that the event was posted by the Amazon IVS chat room. To accomplish a true on-demand replay of a live stream complete with interactive chat replay of a message at the closest moment in time possible, we need to obtain a regular stream of GMT based timestamps from the recorded stream that we can use to determine what chat messages should be visible at any given point in time in the stream playback. There's not currently a documented source that provides this information, but let's poke around with the Amazon IVS and see if we can find something that will help us out with this task. player SDK Amazon IVS Stream Metadata When trying to solve this problem, my first thought was to take a look at the metadata associated with a live stream to see if there is any valuable information hidden within it. Thankfully, there does appear to be a value in the regular stream of metadata that can be used for our chat playback purposes. In my testing, each stream contains ID3 metadata that appears to be injected by the Amazon IVS transcoding process. These ID3 tags contain a helpful timestamp that we can use to help with chat replay. To listen for these events, we can attach a handler that listens for the event type. This event type documented, but the don't say much about it or make any guarantees about what it may contain. IVSPlayer.MetadataEventType.ID3 is docs ? If you're concerned about using an undocumented feature, you could with the proper timestamp when new messages are posted into your Amazon IVS chat rooms. Keep in mind that there are events via the API. Want to Avoid Undocumented Features inject your own timed metadata into your live stream limits to the size and frequency of posting PutMetadata Listening for Metadata Events Let's set up an Amazon IVS player to playback a recorded stream using the Player SDK. First, we'll include the latest Amazon IVS player SDK via a tag. <script> Check out the blog series . If you have questions on getting started, post a comment on any post in that series (or below)! New to Amazon IVS? Getting Started with Amazon Interactive Video Service <script src="https://player.live-video.net/1.16.0/amazon-ivs-player.min.js"></script> As usual, we'll need to include a element in our HTML markup that will be used for playback. <video> <video id="video-player" muted controls autoplay playsinline></video> Now we can create an instance of the IVS player. I'm hardcoding the URL below, but you can obtain this URL via the method described in this post [todo: link]. const streamUrl = 'https://[redacted].cloudfront.net/ivs/v1/[redacted]/[redacted]/2022/11/17/18/6/[redacted]/media/hls/master.m3u8';
const videoEl = document.getElementById('video-player');
const ivsPlayer = IVSPlayer.create();
ivsPlayer.attachHTMLVideoElement(videoEl);
ivsPlayer.load(streamUrl);
ivsPlayer.play(); As mentioned above, to be useful for this purpose, we need a regular stream of timestamps. To figure out how often the ID3 metadata is received, let's add some timing. First, let's capture a timestamp as soon as the stream starts playing. ivsPlayer.addEventListener(IVSPlayer.PlayerState.PLAYING, (evt) => {
  window.time = Date.now();
}); Next, we'll add the ID3 event listener, log the timing, and reset the timer. ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const now = Date.now();
  console.log(`${(now - window.time) / 1000} seconds since last event`);
  window.time = now;
}); Now we can start playback and observe the console to see how often the events are fired. In my testing, the events are fired every 1-2 seconds. It's not realtime, but it's probably good enough for most scenarios. Now let's take a look at the event to see what data it contains. window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  console.log(evt);
}); When we start playback with the listener above attached, we can see the following information logged to the browser console. This is very interesting info, but a bit cryptic. Based on my testing, seems to be timestamp that we're after. Let's modify the event handler to grab that timestamp and log it. transc_s window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const segmentMetadata = evt.find((tag) => tag.desc === 'segmentmetadata');
  const segmentMetadataInfo = JSON.parse(segmentMetadata.info[0]);
  const timestamp = segmentMetadataInfo['transc_s'];
  const timestampWithMs = timestamp * 1000;
  console.log(timestampWithMs);
  console.log(new Date(timestamp));
}); This produces the following output for my test. If I seek to a random moment in the video, the proper timestamp is always correct. This means that every 1-2 seconds we know a valid GMT timestamp of the moment in time that the event was capture in the stream. This means that we can assume that all chat messages that were sent prior to this timestamp have been posted to the chat and should be visible in the chat container. Retrieving the Chat Logs When my page loads, I can utilize the method outlined in the previous post [todo: link] in this series to retrieve the entire chat log for the stream and render it in the chat container . Since no messages should be visible at the very start of the stream, I'll make sure that they call contain a class that hides them from the user and store a data attribute with the proper timestamp so that I can know which messages should be visible given any timestamp in the stream. <div> window.chatLog = await getChatLogs(logGroupName, chatArn, startTime, endTime);
renderChat(); My function handles posting each message to the chat container. renderChat() const renderChat = () => {
  const chatContainer = document.getElementById('chat');
  window.chatLog.forEach(msg => {
    const msgTemplate = document.getElementById('chatMsgTemplate');
    const msgEl = msgTemplate.content.cloneNode(true);
    const ts = new Date(msg.event_timestamp).getTime() * 1000;
    msgEl.querySelector('.msg-container').setAttribute('data-timestamp', ts);
    msgEl.querySelector('.chat-username').innerHTML = msg.payload.Attributes.username;
    msgEl.querySelector('.msg').innerHTML = msg.payload.Content;
    chatContainer.appendChild(msgEl);
  });
}; Now I can modify the ID3 listener to call a function and pass it the current timestamp. replayChat() window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const segmentMetadata = evt.find((tag) => tag.desc === 'segmentmetadata');
  const segmentMetadataInfo = JSON.parse(segmentMetadata.info[0]);
  const timestamp = segmentMetadataInfo['transc_s'];
  const timestampWithMs = timestamp * 1000;
  replayChat(timestampWithMs);
}); In , I can find all of the chat nodes that contain a timestamp less than or equal to the current timestamp from the recorded stream and show/hide any chat message based on that timestamp. replayChat() const replayChat = (currentTimestamp) => {
  Array.from(document.querySelectorAll('[data-timestamp]')).forEach(node => {
    const chatMsgTs = Number(node.getAttribute('data-timestamp'));
    const isVisible = chatMsgTs <= currentTimestamp;
    if (isVisible) {
      node.classList.remove('d-none');
    }
    else {
      node.classList.add('d-none');
    }
  });
  const chatContainer = document.getElementById('chat');
  chatContainer.scrollTop = chatContainer.scrollHeight;
} At this point, we have achieved the goal of playing back a recorded Amazon IVS live stream with a full chat replay. Summary In this post, we looked at how to combine recorded Amazon IVS live streams with logged chat messages to create an on-demand replay of a stream with properly timed chat messages.

Create On-Demand Past Live Stream Playback w/Full Chat Replay on Amazon IVS

Cree reproducción de transmisiones en vivo pasadas bajo demanda con reproducción completa de chat en Amazon IVS

Créez une lecture de flux en direct passés à la demande avec une relecture complète du chat sur Amazon IVS

Amazon IVS पर ऑन-डिमांड पास्ट लाइव स्ट्रीम प्लेबैक w/Full Chat Replay बनाएं

Amazon IVS でフル チャット リプレイを使用して過去のライブ ストリーム再生をオンデマンドで作成する

Crie reprodução de transmissão ao vivo anterior sob demanda com reprodução completa do bate-papo no Amazon IVS

Tạo Phát lại luồng trực tiếp trước đây theo yêu cầu với Phát lại toàn bộ cuộc trò chuyện trên Amazon IVS

在 Amazon IVS 上创建带完整聊天重播的按需过去直播流媒体播放

This short tutorial explains how to replay the captured browser’s network offline using Python. Once you have captured the browser’s network as a HAR file, you can set up a proxy server in order to provide the responses for certain requests which exist in the HAR. Let’s start with creating a dictionary from the HAR. json
dict_url_response = {}
fob = open( , )
data = json.load(fob)
fob.close()
entries = data[ ][ ] entry entries:
    url = entry[ ][ ]
    response = entry[ ]
    dict_url_response[url] = response import "har/cap1.har" "r" "log" "entries" for in "request" "url" "response" Now create a class which we will be using for interception in the proxy. mitmproxy.net.http Response, Headers :
            url = flow.request.url
            har_response = dict_url_response[url]
            text = har_response[ ][ ]
            byt = str.encode(text)
            list_headers = [] obj har_response[ ]:
                list_headers.append((str.encode(obj[ ]), str.encode(obj[ ])))
            headers = Headers(list_headers)
            response = Response(
                http_version = str.encode(har_response[ ]),
                status_code = har_response[ ],
                reason = str.encode(har_response[ ]),
                headers = headers,
                content = byt,
                trailers = ,
                timestamp_start = ,
                timestamp_end = ) KeyError:
            print( )
            headers = Headers([
                ( , ),
            ])
            response = Response(
                http_version = str.encode( ),
                status_code = ,
                reason = str.encode( ),
                headers = headers,
                content = str.encode( ),
                trailers = ,
                timestamp_start = ,
                timestamp_end = )
        flow.response = response from import : class Interception : def request (self, flow) try "content" "text" for in "headers" "name" "value" "httpVersion" "status" "statusText" None 0. 1. except "Request URL not found in HAR" b'Content-Type' b'text/plain; charset=utf-8' "http/2.0" 200 "OK" "Request URL not found in HAR\n" None 0. 1. Finally, we just have to start the MITM proxy with the interception. mitmproxy.options Options mitmproxy.proxy.config ProxyConfig mitmproxy.proxy.server ProxyServer mitmproxy.tools.dump DumpMaster threading asyncio
intercept = Interception() asyncio.set_event_loop(loop)
    m.run_loop(loop.run_forever)
options = Options(
    listen_host= ,
    listen_port= ,
    http2= )
m = DumpMaster(
    options,
    with_termlog= ,
    with_dumper= )
m.addons.add(intercept)
config = ProxyConfig(options)
m.server = ProxyServer(config)
loop = asyncio.get_event_loop()
t = threading.Thread(
    target=thread_func,
    args=(loop, m)
)
t.start() from import from import from import from import import import : def thread_func (loop, m) '0.0.0.0' 8080 True True True The is used in order to keep the proxy server running. The proxy server listens on . thread_func 127.0.0.1:8080 In order to test the HAR replay you have to make the browser go through the proxy server, e.g. for Chrome the command would be: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server=127.0.0.1:8080 Sometimes the requests that are captured in the HAR are gzip or brotli compressed. In this GitHub repository such cases are taken into account: https://github.com/endgame-is-on/HAReplay Also published on Medium's endgame-is-on

Follow These Steps To Replay Browser’s Network Offline

Agile Maturity and Agility Assessment (Webinar #2 Replay)

Below are the slides and a video replay of the incredibly dense and informative conference call we held on Token on November 6th. Thanks & . You guys were all awesome! Economics Tom Bollich Mark Smargon Ben Perper Jake Brukhman Enjoy! to Tom Bollich’s slides Here’s the link to slides Mark Smargon’s slides Here’s the link to Ben Perper’s slides Here’s the link to Jake Brukhman’s slides Here’s the link 0.00000001 If you got at least Bitcoin worth of value from this post please “Clap” below so others will see the post.

Replay of “The Emerging Science of Token Economics” — Conf. Call Held on Nov. 6

Replay of “ of Acquired on The End of Government, The Death of Apple and The Amazon Apocalypse” Ben Gilbert <a href="https://medium.com/media/b91b1eba474c461240d42809716b1698/href">https://medium.com/media/b91b1eba474c461240d42809716b1698/href</a> Ben Gilbert’s an ex-Microsoft guy with a passion for startups and growth. He runs Pioneer Square Labs, an innovative venture studio that after raising $12M, has cranked out half a dozen successful startup spin offs — think Rocket Internet without the copy/paste. Ben is also the co-host of the Acquired podcast where he and of discuss the most prolific acquisitions and IPOs in tech history. David Rosenthal MD Madrona Venture Group Listen and Learn: Why most acquisitions and IPOs fail An unconventional and effective approach to venture How to spin out a startup What driverless cars mean for the future Why Apple is in trouble and Google’s business model is over The future of IPOs and the stock market How Amazon will own everything Why Facebook is the king of acquisitions Check out the Original Episode Here! Itunes: Android: http://thesyndicate.vc/itunes http://thesyndicate.vc/android If you got something actionable or valuable from this post or enjoyed the interview, go ahead and “Clap” below .

Replay of “Ben Gilbert of Acquired on The End of Government, The Death of Apple and The Amazon…

<a href="https://medium.com/media/e8b549c99d037ec1d7c060ac5bed77a5/href">https://medium.com/media/e8b549c99d037ec1d7c060ac5bed77a5/href</a> Zach is a 4 time entrepreneur, full time angel investor and all around good and helpful guy. His Cruise Automation syndicate was the first billion dollar exit on AngelList and he’s invested and advised several more startups well on their way to the coveted unicorn status. Before starting investing, Zach’s company Triggit raised ~$18M in funding before being acquired. Listen and Learn: Why it is better to be good and lucky The value of social proof with co-investors How to build a top 10 AngelList syndicate The massive opportunity in South East Asia Why competitive markets kill startups Poker and meeting startup founders The way to add value to entrepreneurs How to invest unicorns Click to Check out the Original Episode and Much More! Itunes: Android: http://thesyndicate.vc/itunes http://thesyndicate.vc/android If you got something actionable or valuable from this post or enjoyed the interview, go ahead and “Clap” below .

Replay of “Zach Coelius on 1st Billion Dollar AngelList Exit and Building a Top Tier Syndicate”

to Ari Paul’s slides Here’s the link to Gil Penchina’s slides Here’s the link to Trevor Korverko’s slides Here’s the link Our best attended cypto conference call to date was this remarkably informative call on September 7th, “How To Value Cryptocurrency”, which was a macro look at crypto valuation: The blog post “ ” is my second most read crypto piece to date (after a recent big picture crypto post “ …”). The 7 Things You Need To Know From The Valuing Cryptocurrency Conference Call 7 Thoughts Now, with , September (at over $800 million), and almost two months since (2 months in cryptoland = 2 years ), we felt it was time to re-visit crypto valuation, but from a micro perspective. Bitcoin blowing through $5,000 breaking the record for ICO funding our last valuation call IRL On this call, we’re asking three leading crypto investors to each pick one crypto investment, and walk through in detail why they believe it’s a good investment, what are the factors they see that are likely to drive the price higher, and the risks they’ve identified that they’re willing to accept for their perceived upside. While we generally have four speakers on a call, we’re excited to have only three renowned crypto investors on this call, leaving more room, after the prepared remark,s for questions from the audience. Click here to register for the call at GoToWebinar Speaker Bios: a leading cryptocurrency investment firm. Ari was previously a portfolio manager for the University of Chicago’s $8 billion endowment, and a derivatives market maker and proprietary trader for Susquehanna International Group (SIG). Ari Paul — Co-founder and CIO of BlockTower Capital , the world’s first automated sweepstakes protocol. Gil is a serial entrepreneur, and prolific angel investor. He is the former founder of Flight.vc, co-founder of Fastly, CEO of Wikia, and was a member of the pre-IPO team at eBay. He is a partner at Ridge Ventures and an investor in 70+ companies over the last 12 years, including: AngelList, Brave, Ripple, Filecoin, Civic, and Dollar Shave Club. Gil Penchina — Co-founder and Advisor at Pryze an open platform that gives businesses access to the , smart contracts and token creation technology. Prior to Polymath, Trevor was a crypto investor and advisor to projects including the Ethereum project. Earlier Trevor founded eProf.com, an online education platform, Digital Assets Int’l, a tech private equity firm, and an Oculus Rift-based project that became the world’s first VR exit. Trevor was a professional hockey player after being drafted by the NY Rangers in 2005. Trevor Koverko — Founder of Polymath, blockchain Click here to register for the call at GoToWebinar 0.00000001 Bitcoin If you got at least worth of value from this post or enjoyed the video, go ahead and “Clap” below .

Stories, News & Mentions about REPLAY

Replay’s Stories on HackerNoon