Block Green is a financial marketplace for Bitcoin 

Block Green

1. Introduction 2. Basic knowledge 3. Seeing through the backdoor 3.1 HTML elements 3.2 CSS defaults 3.3 Display Property 3.4 Display attributes 4. Conclusions 1. Introduction: HTML and CSS is the common door for people who want to become a web developer. Many of them start from zero and have no programming knowledge at all. Others have some coding experience. I had a programmer background when I started learning HTML but had no idea about this new world. Going through tutorials helped me memorize some properties and styling the elements. Learning While I was learning people were struggling to display or position HTML elements. We were all trying to, but we didn't knew which property will do the job and we'd try them one by one until we found the one. HTML and CSS can be very confusing if you don't get the real core of it, what do I mean by "Get the real core of it"? Actually what I mean is to undress the structure itself, to see what happens behind the curtains. This will change the rest of your journey with HTML and CSS. It'll make you faster at coding and you'll easily find out how to position elements on a web page. You'll even find out how did elements were positioned in other web pages just by looking at it. 2. Basic Knowledge: There are 3 main things I'd like to address here so you can see what I'm talking about. These 3 main qualities will get you to understand how things run in the background of HTML and . Before getting into it, please make sure you already know how to create HTML documents and to apply styling to its elements. If you don't know how to create HTML documents and to add styling to its elements, please go to freecodecamp.org and complete the basic tutorials. CSS 3. Seeing Through The Backdoor Of HTML And CSS: As I said before there are 3 main things you should be aware of while learning HTML and CSS. The main thing you should understand is the way an HTML document is filled. What do I mean by this? What I mean is that the document will be filled out with the elements you add to it. But they certainly won't be positioned as you expected. 3.1 Filling The Body Of The HTML Document Once you understand that the document will be filled from left to right, from top to bottom. You'll know that the HTML body works like a container on which elements will be added one next to the other, from left to right (depending on their display property). Once the line has been filled, the next element will go to the first space of the next line, this will be repeated as a new line is required. An HTML document can be filled 100% in width but not in height, otherwise, you wouldn't be able to scroll up or down and the page would be limited in vertical space. Imagine 5 division elements, all of them were set with width and height of 50px, how would they look on the page? Try it yourself! Were you expecting them to be under one line instead of one column? It seems like is not filling the page as I told you before, right? This is because divisions have a display default value to block. Even if the width was bnh to 50px it'll occupy the whole line, limiting its content to 50px. This is because you have set a 50px width and the previous division is a block and it needs to fill his line completely. Note: The body needs to be set first, set the width to 100% and the height to 1000px. This way you can work inside this container. 3.2 CSS Defaults You need to know that CSS defaults are applied to the elements by the browser, What does this mean? It means that if the browser doesn't apply the defaults to the HTML elements they would all be the same. Divisions, anchors, forms, paragraphs, all of them would be the same. This means that basic elements like divisions, anchors, and all of them would load as an element with no value within its properties and they would look all the same. Being aware of this will let you understand that you don't need to overthink which elements to use. 3.3 Display Property Displaying and positioning are 2 things must of us struggle with. Knowing the 2 main things I mentioned before will make it easier for you to position elements any way you want. But the real deal is in the display property. The display property will change the behavior of the element positioning and display. Remember the defaults I mentioned before? Yeah! The display property is already set to a value on all HTML elements, so they will be displayed as the default value dictates. The default value for division elements is "block", this means it will occupy the whole width of a line. Remember the divisions we added before? You can make them show in a row just by changing the display property on each! Give it a try with the inline-block value. Do you see it now? Divisions are shown in a row instead of a column. Now try this: Box 1 - block, Box 2 - inline, Box 3 - inline, Box 4 - block, Box 5 - Inline-block. The display property can be set to other values like flex, inline-flex, inline-table, etc. Your code should look like this: HTML: html lang="en"> Box 1 Box 2 Box 3 Box 4 Box 5 < > head < = = = /> link href "style.css" rel "stylesheet" type "text/css" </ > head < > body < = > div class "box1 size" </ > div < = > div class "box2 size" </ > div < = > div class "box3 size" </ > div < = > div class "box4 size " </ > div < = > div class "box5 size display" </ > div </ > body </ > html CSS: { : ; : gray; : ;
} { : block; : blue;
} { : inline; : yellow;
} { : inline; : red;
} { : block; : green;
} { : orange;
} { : ; : ;
} { : ;
} body width 100% background-color height 1000px .box1 display background-color .box2 display background-color .box3 display background-color .box4 display background-color .box5 background-color .size width 50px height 50px .display display 3.4 Display attributes Last but not least, I wanted to add that there are properties that are specific for a type of display value. This means that when you set a display value to an element, you can address it with some specific properties like the flex display value for example. The Flex display value can only be "handled" by properties like: align-content, justify-content, align-items, flex-direction. Setting a different display value will make you change the way you are "addressing" to it. Conclusions: Putting these 3 main things together expands your notion of positioning and displaying of HTML elements and now you can easily accommodate elements by: Knowing how the page is going to be filled, depending on the display property of the element itself. Determinate what display value works the best for the element you are adding to your layout. Knowing some CSS defaults were loaded to the element you just added, you can try to override the default value to position better your element. Using the correct properties for each display value. Now you can go ahead and try exploring a website, pick an element on that web page, and ask yourself...How could I position that element the same way they did? If you are having some ideas go ahead and try them! Even if they don't look the same, you could use only the container with some borders!

How To Understand HTML and CSS For Beginners

N ew technologies are evolving rapidly. Some of the newest solutions are gaining popularity every day. Optical Character Recognition (OCR) is nothing new, but perfecting it with machine learning may shed a new light on OCR. It’s obviously a broad subject. Nevertheless, I’ll try to briefly introduce you to the machine learning within OCR implementation on Android. I’ll also present some of its functions, basing on an easily available software called Google Firebase ML Kit. What is OCR? Nowadays, almost everything is digital. Books, newspapers, articles — name it. So what can be done to make a written or printed text digitized or even translated? Optical Character Recognition (OCR) comes with the solution. It’s capable of finding the text on the images and making it digital. Whenever you need to split the expenses between you and your friends — it’s always a problem. Who and how much should pay for pizza or drinks? Now, you can take a photo of a receipt and an application on your smartphone can split the expenses for you. It can even send the reminders about the payment to your friends. Also, searching for the information about a bus line may be easier. By taking a photo of a bus number or a name of a bus stop, you can get the information about a bus line you need. How does it work? Computers are dumb themselves and can’t recognize anything from an image. For them, every picture is just a bunch of pixels, basic information about colours. To help the computer find what you need, we can teach it how to recognize the letters. It’s known as a pattern recognition. It can be used for a text that has the same font, size and spacing from the top to the bottom. But what if we have different fonts and sizes throughout the text? To help the computer, detection feature needs to be introduced. Detection feature or intelligent character recognition (ICR) is used to identify characters’ traits. It searches for the letters that meet the specified requirements. For example: if you see two angled lines that meet in a point at the top and there’s a horizontal line between them about halfway down, that’s the letter A. Majority of OCR software uses a detection feature, rather than a pattern recognition, to find the letters on images. Some of them use machine learning to teach the software how to recognize the characteristics of the letters. OCR implementation on Android Google Firebase ML Kit is a set of the tools which helps to implement machine learning on Android and iOS — OCR is one of them. It’s relatively easy to start using machine learning. ML Kit has some built-in modules that enable text recognition, face detection, barcode scanning and more. If you’re experienced in neural networks and want to use more sophisticated or specialized ML, you can use custom Tensorflow models. ML Kit has two versions: on-device and cloud. You’ll find the differences and all the features of both versions . We’ll focus on the Android on-device version below. here Before we start, we need to create the Firebase project in the Firebase Console. Tutorial can be found . It requires the knowledge of Kotlin programming language and RxJava2. here Now, let’s add the Firebase ML Kit module in and gradle dependency. AndroidManifest.xml With this setup we can start implementing our text detector. We need to create . FirebaseVisionTextDetector Now, we have the instance of Vision detector which is used to detect the text on the images. To do that, we use: This method takes instance of as a parameter and produces . When task is ready, we can grab . It contains the data about the detected text and the bounding boxes of the detected areas. FirebaseVisionImage Task<FirebaseVisionText> FirebaseVisionText You can create from a bitmap, using a method below: FirebaseVisionImage There are other factory methods to create FirebaseVisionImage. We can check them in Firebase documentation. For now, we’ll use a bitmap version. Below I’ve implemented the full detector class. I’ve used RxJava2 to process input and output of the text detector. I also wrapped Firebase class in to detect the text on RxJava stream. Task<T> Flowable Full class: TextDetector Important points in the class above are and functions. First one is an input point and the other is an output for our detections which you can listen to. processImage observeDetections Now, we need to draw detections on the scanned image. All the bounding boxes come from the object. FirebaseVisionText contains blocks, lines and elements. Blocks are the largest areas of the text, each block has lines and all the lines have elements. FirebaseVisionText Knowing this, we can draw all these elements on our input bitmap. To do that, we need to gather all the bounding boxes for each unit and then draw rectangles on a bitmap. Below, there’s a complete snippet: Output code will look like this: Blue border represents the block, green represents the line and white represents the element. Pretty much all the text was found. Testing the text recognition on receipts example I decided to test three receipts and check how Google’s text recognition will handle them. Each receipt was in different language: Polish, Spanish and German. I’m unable to test languages different than Latin-based, because on-device version doesn’t support them. To test languages like Greek or Russian, the cloud version is required. The first receipt was in Polish. Below, we can see two images. Text highlighted on the left image shows what have been detected by ML Kit. On the right image there’s a data returned by API, drawn on white background. It seems pretty much the same as on the original image. Of course, there were some issues with formatting. Also some letters weren’t detected or were confused. Besides that, we can see that the results were rather good. I aligned all the lines vertically and adjusted the text size to the boxes, what you can see below. Without these corrections there was much more mess. The second test was performed on the Spanish receipt. This one was in low resolution (225 x 335px). As we can see, detector found only two blocks on the entire image. And the last attempt was on the Swiss receipt in German. Detection was almost faultless. Whole text was found, except “e-mail” at the bottom of the receipt. Detector only found last letter of “email” word and assumed it’s 1 (number one). Summary I’ve presented you the overview of OCR basics. I also showed the OCR implementation on Android using Google’s ML Kit. Implementation of ML Kit is rather simple and doesn’t need that much coding. When using an on-device version, detection is limited to the Latin-based languages. Scanned images must have a decent resolution to get good results. Detector doesn’t recognize some of the letters or confuses them. Also, there are some problems with the text written vertically. To get better results, cloud version, other specialized OCR software or custom Tensorflow model are required. On-device text recognition can be used to detect keywords or some simple information from larger text rather than extended articles. As I’ve mentioned earlier, OCR is nothing new at all. But introduction of machine learning within this technology may significantly improve it. In the nearest future we may witness extended, smart OCR implementation, version 2.0. Who knows? The article was written by Łukasz Gawron and was first published on The Software House Blog . Visit the blog for more articles on best development practices and software outsourcing tips.

Simple OCR implementation on Android with Google’s ML Kit

Tech news today is, in a word, bleak. Though things will hopefully change by the time you read this article, current headlines center in on , the (with layoffs, resignations, and Elon Musk himself warning of bankruptcy), and the in the massive cryptocurrency exchange called FTX, which filed for bankruptcy last week. tech layoffs state of Twitter likelihood of fraud In between all that, I had the pleasure of hearing an inspiring software engineer story at . FreeCodeCamp Sacramento David Ballowe is an Environmental Science major who worked as a media production lead for three years. He spent six months as a self-taught developer before receiving a full-time offer at a small media technology company. He achieved this without having to pursue a second college degree or pay for an expensive, formalized coding boot camp. After reading so many articles and forum posts about how to land a first software engineer job, David wanted to share his advice and story. Resources David’s strongest recommendation was for a . This is the part where I will (annoyingly) insert myself into the story - I personally have a fairly generic background of studying computer science at a four-year university, becoming a software engineer right out of college, and remaining in one place for six years - but from what I gather, . Harvard course called CS50 CS50 is a completely free computer science course that, in spite of being aimed at beginners, is extremely challenging I found a popular YouTube channel , describing it not just as a course but as a movement. In 11 weeks, students go from learning Scratch to covering binary, C, and enough web development languages/concepts to build full-fledged web applications at the end of the year ( …another choice is mobile applications in Swift). praising it here or anything they want to create, really The lecturers are enthusiastic and give demonstrations; for example, one lecture consists of a professor using lightbulbs to teach binary. There are weekly, graded problem sets. The entire experience is a simulation of a real-life university experience. David’s second recommendation was for , a free and open-source web development resource. The Odin Project David’s Generic Advice: Avoid Tutorial Hell. Do not just watch hours and hours of YouTube videos. Build something, like a weather app or a calculator app. Bootcamp is usually available for free. He was able to build personal lists of boot camp curriculum, including what students built, to aid in his self-studying. curriculum When you build personal projects and showcase them on a personal portfolio, do not simply rehash things that popular YouTube channels walk you through. David’s Advice for Projects Design, in his opinion, is very important. David recommends buying a personal domain and building projects that , who could quickly reject a candidate simply for making a website that looks bad. look impressive even to non-technical people One of David’s projects, for example, can carry out simple online transactions. David’s Process for Applying for Jobs Before first interviewing for a company, David would research the company “pitch,” download the company app, if a single one existed and was available, and look into the person interviewing him. He had success simply testing out an application, which impressed HR, and asking a former PlayStation engineer what it was like to work there. , and He used multiple resumes that were customized for different job descriptions whenever he applied for jobs, he filtered out openings that were more than three days old or had more than 70 applicants. He used AngelList, Indeed, and LinkedIn. . Every interview he got was using LinkedIn easy-apply Though he did study data structures and algorithms, he personally found it was much more common to receive take-home project assignments. A Few Caveats During this entire process, David had a very understanding boss who understood his career goals. David was able to work part-time and treat this job application/studying effort like it was a second job. David worked at this for 6-10 hours a day, and his GitHub during this time was a solid green block. David did not cite specific resources as particularly helpful when it came to UI/UX, but his background in media was beneficial. Why It Matters The debate over the pros and cons of becoming a software engineer via university education, a coding boot camp, or self-study is a contentious one; it is also beyond the scope of this story. What matters here is that . there are free resources available designed to simulate the community, the rigor, and the pacing of a real university education Unlike some of their alternatives, these resources do not rely on revenue from monthly subscriptions, $7000 upfront payments, or binding contracts that allow you to receive education only after pledging a cut of your first 24 monthly paychecks, or the promise of working at a specific company and location for two years to pay back a debt. The path to software engineering is one that requires discipline and drive. This story is an example of how one person with enough discipline and drive can bypass the more expensive part of the aforementioned journey. As the tech market experiences turbulence, such a path sounds increasingly appealing.

From Media Production Lead to Full Stack Engineer in Six Months

De líder de producción de medios a ingeniero de full stack en seis meses

De responsable de la production multimédia à ingénieur Full Stack en six mois

छह महीने में मीडिया प्रोडक्शन लीड से लेकर फुल स्टैक इंजीनियर तक

6 か月でメディア プロダクション リードからフルスタック エンジニアに

De líder de produção de mídia a engenheiro de pilha completa em seis meses

Từ trưởng nhóm sản xuất phương tiện đến kỹ sư full stack trong sáu tháng

在六个月内从媒体制作负责人到全栈工程师

Taproot. Source: https://academy.binance.com/ I was never a huge fan of Bitcoin. In fact, I actually it. disliked Although I really resonate with the values of decentralization and privacy that Bitcoin was created for in the first place, it has so far been unable to achieve them at all. The large amount of computational power required to solve the preimage hash puzzles renders it so that . The ability to verify transactions in the network will only ever be available to those who have the means to own a large quantity of the very powerful and expensive ASIC mining machines (that are used to solve said puzzles). true decentralization in Bitcoin will always be a mere pipe dream We see that very clearly today, with most network hashing power coming from only a few of the largest mining pools. In short, there is no true decentralization of power when it comes to the Bitcoin network. Moreover, transactions on the Bitcoin network will also never truly be anonymous. Sure, the only thing you’ll actually reveal when transacting on the Bitcoin network is your public address. Since this address has been hashed by a cryptographic function and a digital signature algorithm (SHA-256 and ECDSA respectively) to prevent reverse-engineering, surely it provides full anonymity, right? Wrong. In actuality, it is easier than most people think to connect a public address on the digital Bitcoin ledger to a real world identity. You may not even need programming skills to do that! Many organisations — even individuals — have successfully done so before. Here, we come to the realisation there is also no true privacy when we transact on the Bitcoin network. In sum, Bitcoin was born out of fantastic principles, but has failed to live up to them due to the difference between theoretical musings, and real-world application. This is why I have never really liked Bitcoin, and have always hoped that its immense market dominance will one day be flipped by a substantively more useful project like Ethereum. Bitcoin’s reign as the ‘big brother’ of the blockchain and cryptocurrency world must surely be coming to a swift end due to its many limitations and inability to live up to its founding principles. Or so I thought. Now with the Taproot update in the works, . everything has changed Taproot’s Background Story Before I dive into its exact details, let me first give you a better idea of the contextual background that the Taproot update is set against. In January 2018, Bitcoin Core developer Greg Maxwell formally released the Taproot Update proposal. On June 12 2021, 3.5 years later, Taproot officially gained enough mining support to lock in activation. To elaborate, at least 1,815 out of the 2,016 blocks mined within the most recently designated two-week difficulty period (or most recent ‘voting’ round) have been found to include information that points toward the miners being in collective favor (90% or more) of the Taproot upgrade. During this particular difficulty period, and at block 687284, this 90% threshold was finally met. In fact, by the time this two-week difficulty period ends on Sunday, it is likely the Taproot upgrade will have locked in with over 99% of blocks signaling decisively in its favor. This is in sharp contrast to Bitcoin’s most recent upgrade in 2017, sometimes referred to as the ‘Civil War’, where an ideological split within the Bitcoin community itself led to a hard fork, culminating in two distinct projects, Bitcoin Cash and Bitcoin. Adherents who followed the former wanted to improve transaction speeds by increasing the maximum block size to 8mb, whilst the latter deployed the Segregated Witness (SegWit) upgrade that separates Digital Signatures from transaction metadata in order to reduce storage load, to do so. This time, however, Taproot has near universal support. This rare moment of collective consensus is largely due to the fact that the proposed changes represent monumental improvements to Bitcoin’s protocol that will radically increase its capacity to push forth several key functions that are principal to Bitcoin’s very existence (and that I will be discussing later). The ‘voting’ results. A green block means that it signaled readiness for Taproot activation. A red block means that it did not. Transparent blocks represent upcoming blocks within this difficulty period. Source: Taproot.watch What is Taproot, and what improvements will it bring? The Taproot upgrade will bring about two main improvements to the Bitcoin network: Increased Privacy for Multisig transactions Potential for Smart Contracts (Scalability) Before I elaborate on these improvements however, it is pertinent to look at extant protocols within the Bitcoin network first, for you to get a better idea of how Taproot constitutes an improvement over them. Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA curve. Source: https://metamug.com/ Currently, Bitcoin utilises the Elliptic Curve Digital Signature Algorithm (ECDSA) to derive public keys from randomly generated private keys (by using elliptic curve point scalar multiplication by n), and subsequently — the public Bitcoin addresses (after hashing the public key with the quantum-resistant SHA-256, and RIPEMD160). What is special about the ECDSA is that it ensures that the aforementioned hashing process cannot be reverse-engineered. That is to say, ECDSA renders it such that it will be mathematically impossible to derive someone’s private key from his/her Bitcoin address or public key (because secp256k1, Bitcoin’s elliptic curve, ensures a trapdoor, or one-way function). This is to protect and enforce ownership rights within the Bitcoin network because your private key is your passport to the Bitcoin network. It’s what allows you to generate an address for receiving coins, and what later allows you to spend them. If someone is able to derive private keys from your addresses, the Bitcoin network will not even be functional. The ECDSA (and SHA-256) makes sure that this does not happen. Now, let’s say an individual — Alice, wants to make a transaction to another individual — Bob, on the Bitcoin network. She will have to sign on her message (dictating the transaction; ie. ) with her ECDSA-generated private key. This will generate a unique digital signature that proves that Alice created the message as it is. ‘I am sending you these coins that have been previously sent to me’ She then sends her signature along with her original message to Bob. The idea is that the message is the main payload, and the digital signature is used to prove that Alice was truly the one who created that exact message. Bob is then able to easily verify that the digital signature is valid, given Alice’s public key and the original message. And if the signature is valid, that means the message wasn’t tampered with. Therefore, this is how digital signature schemes make messages tamper evident. Another key point is that Bob or anyone else should not be able to guess Alice’s private key, given just her public key. Otherwise, Bob or anyone else would be able to recreate Alice’s signatures and thus fake her identity. This is why the ECDSA is of utmost importance for transactions on the Bitcoin network. Downsides of ECDSA However, even though the ECDSA scheme has been working well for the network for more than a decade now, it also has its drawbacks. For one, it is not the best scheme for especially for users who transact using complex functionalities like Multisig (multi-signature) transactions. privacy, For another, it is also not the best scheme to use if the Bitcoin network wants to because for users who transact using the aforementioned complex functionalities, their transactions will take up a lot of bandwidth and storage space on the network. scale, This is where Taproot, and specifically — the Schnorr signature scheme it brings along with it — comes into play. The Schnorr Signature Scheme The Schnorr Signature scheme operates similarly to ECDSA in that it allows for the generation of private and public keys in a safe and reliable manner. However, and for all intents and purposes, the former is over the latter. vastly superior So the question that should be on all your minds right now — why didn’t Satoshi Nakamoto just use Schnorr signatures from the very beginning then? This is mainly because the creator of Schnorr signatures, Claus P. Schnorr, actually them. As a result, Schnorr signatures were rarely used, if at all. Therefore, Satoshi decided to go with the more proven, more widely-accepted and open source (therefore possessing more ostensible longevity) ECDSA scheme. patented Claus-Peter Schnorr. Source: https://owpdb.mfo.de/ However, now with the Taproot upgrade all but an eventuality, and assuming all nodes will adopt the software upgrade — every user on the Bitcoin network will switch over from the ECDSA scheme to the Schnorr Signature scheme by the end of 2021. At this juncture, it should be pretty clear to you that Schnorr signatures are at the very heart — if not the heart — of the benefits that Taproot will bring to the Bitcoin network at large. So if anyone were to ask you about what Taproot brings to the table, just tell them about Schnorr signatures! already Benefits of Schnorr Signatures If you recall, I mentioned above that the Taproot upgrade will bring about two main improvements to the Bitcoin network: Increased Privacy for Multisig transactionsPotential for Scalability Both these improvements are only possible because of Schnorr signatures. Increased Privacy for Multisig transactions With ECDSA, it will always be very obvious whenever a or Multisig address initiates a transaction on the network due to the simple fact that all such addresses will begin with a number ‘3’. Therefore, transactions from any given Multisig address will be distinctly recognizable for anyone who just bothers to look at the ledger. m-of-m m-of-n Visual representation of a m-of-n (1-of-2) Multisig transaction. Source: https://docs.symbolplatform.com/ This isn’t great at all from a privacy standpoint, especially since Multisig transactions are meant to enable greater security for all the users involved. Schnorr signatures counteract this problem by allowing for a very important function — This signature aggregation function allows for the combining of multiple signatures into one singular signature, or what is termed as the ‘master’ signature. This master signature will make it a lot more difficult, or even impossible, for an observer to determine who signed (or didn’t sign) in any given or Multisig transaction. signature aggregation. m-on-m m-of-n Signature Aggregation in Schnorr signatures. Source: https://www.dcforecasts.com/ Although Schnorr signatures, and Taproot by extension, won’t provide any greater anonymity or privacy for your individual bitcoin addresses, it will certainly make simple transactions indistinguishable from those that are more complex and composed of multiple signatures. This will benefit the latter group to no end in terms of privacy — something that the ECDSA scheme currently does not help with. Potential for Scalability Moreover, with ECDSA, large-scale Multisig transactions will take up a lot of space and bandwidth on the Bitcoin network as everyone involved in such a transaction will have to provide their valid digital signatures and public keys to the network. For example, if a 7-of-7 Multisig address wants to make a transaction, this would mean that 7 pairs of digital signatures and public keys will have to be generated to the network. Schnorr signatures’ aforementioned function thus enables significant space savings due to the fact that the master signatures generated will be of the same length as regular, one-person signatures. signature aggregation If we were to use the 7-of-7 Multisig address transaction analogy from above — there is no longer a need to store 7 pairs of digital signatures and public keys on the network with the Schnorr Signature scheme. These smaller and faster signatures are absolutely a huge game changer when it comes to the scalability of the Bitcoin network. There has even been talk of an implementation of complex on the Bitcoin network due to Schnorr signatures’ enablement of more flexible and accessible discrete log contracts (DLCs). smart contracts Additionally, Schnorr signatures have also been theorized to allow for something called a “batched validation”, wherein Bitcoin full nodes will be able to validate 1,000 Taproot signatures in nearly the same time it takes to validate one ECDSA signature. This Schnorr signature-empowered scaling solution would thussignificantly shorten the time it takes a node to verify all signatures in a block, potentially increasing transaction speed and throughput exponentially. Further, Schnorr signatures could also potentially help scale related layer-2 blockchain platforms like the Lightning Network (a payment channel built on top of the Bitcoin network that enables instant transactions) too. Bitcoin’s Lightning Network. Source: https://blog.blockonomics.co/ They can do so by introducing to Lightning as a notable upgrade on the extant . This will ultimately allow for more private and efficient smart contracts to be built on Lightning, potentially resulting in significant increments in transaction speed and throughput. Point Time-lock Contracts (PTLC) Hash Time-lock Contracts (HTLC) Final Thoughts on Taproot In all, the Taproot upgrade is a very promising one that has made me change my mind a little with regard to Bitcoin; it may just be the very spark that brings Bitcoin back to the core principles upon which it was so nobly founded upon by Satoshi Nakamoto, and that I fell in love with. However, and as with everything in life — theory and real-world application are two very very different things. Taproot can sound perfect on paper; how it is implemented remains very much to be seen. If Taproot can even deliver on 50% of what it promises, the moon (or even beyond) will become the literal limit for Bitcoin. Who knows, it may even venture into the fabled DeFi space and become a juggernaut there. When all is said and done, and the upgrade is finally rolled out in November 2021, I may just become the biggest Bitcoin fan yet. Only time will tell.

A Makeover that Changes Everything: The Bitcoin Taproot Update

OpenAI successfully trained a network that can generate images from text captions. It is very similar to GPT-3 and Image GPT and produces amazing results. DALL-E is a new neural network developed by OpenAI based on GPT-3. In fact, it’s a smaller version of GPT-3 using instead of 175 billion. But it has been specifically trained to generate images from text descriptions, using a dataset of text-image pairs instead of a very broad dataset like GPT-3. It can create images from text captions using natural language, just like GPT-3 creates websites and stories. 12-billion parameters Project link: https://openai.com/blog/dall-e/​ Follow me for more AI content: ►Instagram: ​ https://www.instagram.com/whats_ai/ ►LinkedIn: ​ https://www.linkedin.com/in/whats-ai/ ►Twitter: ​ https://twitter.com/Whats_AI ►Facebook: ​ https://www.facebook.com/whats.artifi... ►Medium: ​ https://medium.com/@whats_ai The best courses in AI: ► ​ https://www.omologapps.com/whats-ai Join Our Discord channel, Learn AI Together: ► ​ https://discord.gg/learnaitogether Become a member of the YouTube community and support my work: https://www.youtube.com/channel/UCUzG... Video Transcript 00:00 openai successfully trained a network 00:02 able to generate images from text 00:04 captions 00:05 it's very similar to gpt3 and image gpt 00:09 and produces amazing results let's see 00:12 what it's really capable of 00:14 this is what's ai and i share artificial 00:16 intelligence news every week 00:18 if you are new to the channel and want 00:20 to stay up to date please consider 00:21 subscribing to not miss any further news 00:24 dolly is a new neural network developed 00:27 by openai based on gpt3 00:29 in fact it's a smaller version of gpt3 00:32 using 00:32 12 billion parameters instead of 175 00:36 billion parameters 00:38 but it has been specifically trained to 00:40 generate images from text descriptions 00:42 using a data set of text image pairs 00:45 instead of very broad 00:46 data set like gpt3 it can generate 00:50 images from text captions 00:51 using natural language just like gpt3 00:54 can create 00:55 websites and stories it's a continuation 00:58 of msgpt and gpt3 that i both covered in 01:01 previous videos if you haven't watched 01:03 them yet 01:04 dolly is very similar to gpt3 in the way 01:07 that it's also a transformer language 01:10 model 01:10 receiving text and images as inputs to 01:13 output a final transformed 01:15 image in many forms it can edit 01:17 attributes of specific objects 01:19 in images as you can see here or even 01:22 control multiple objects and their 01:24 attributes at the same time 01:26 this is a very complicated task since 01:29 the network has to understand the 01:30 relation between the objects 01:32 and create an image based on its 01:34 understanding 01:36 just take this example feeding to the 01:38 network an emoji 01:40 of a baby penguin wearing a blue hat 01:43 red gloves green shirt and yellow pens 01:46 all these components need to be 01:48 understood the objects colors and even 01:51 the location of the objects 01:54 meaning that the gloves need to be both 01:56 red and on the hands on the penguin 01:58 the same thing for the rest and the 02:00 results are very impressive considering 02:02 the complexity of the task 02:05 we can just see another more simple 02:07 example where we just fed 02:09 a small red block sitting on a large 02:11 green block 02:12 to the network now it just needs to know 02:15 that there are two blocks 02:16 their colors and one being smaller and 02:19 the other bigger 02:20 this seems very simple to us but it 02:23 needs a really high level of 02:25 understanding to be able to achieve this 02:28 it is still 02:29 not perfect as you can see but we are 02:31 getting pretty close 02:33 dolly is also able to change the 02:35 viewpoint of a scene 02:36 for example here we send an extreme 02:38 close-up view of an eagle 02:40 on a mountain and these are the results 02:43 here we just changed the eagle for a fox 02:46 and this is what is generated 02:50 of course a simple caption can produce 02:52 an infinitude of plausible images 02:54 nobody knows what you have in mind if 02:57 you think of a painting of a fox 02:59 sitting in a field at sunrise there are 03:02 many variables 03:03 such as the fox itself its colors where 03:06 it is looking at 03:07 its position and we are not even talking 03:10 about the background and the style of 03:11 the painting 03:12 fortunately since it is very similar to 03:14 gpt3 we can 03:16 add details to the input text and 03:17 generate something much closer to what 03:20 we expected 03:20 just as you can see here with different 03:22 styles of paintings 03:25 it can also generate images using 03:27 objects that are not related to each 03:30 other 03:30 like creating a realistic avocado chair 03:33 or generate original and unseen 03:35 illustrations 03:36 like a new emoji in short they described 03:39 dolly as a simple 03:40 decoder only transformer if you are not 03:43 familiar with transformers you should 03:44 definitely watch the video i made 03:46 covering them 03:48 as i mentioned it receives both the text 03:50 and an image as inputs 03:52 in the form of tokens just like gpt3 to 03:55 produce a transformed image 03:57 it uses self-attention as i described in 03:59 a previous video to understand the 04:01 context of the text 04:02 and sparse attention for the images 04:05 there are not many details about how it 04:07 works or how exactly it was trained 04:09 but they will be publishing a paper 04:11 explaining their approach 04:12 in short this daily network shows that 04:15 manipulating visual concepts 04:17 through language is now within reach and 04:20 i am excited to read their occurring 04:22 paper 04:23 of course this was just an overview of 04:25 this new openai network 04:27 called dolly i strongly invite you to 04:30 follow openai's news 04:31 about the upcoming paper for a better 04:33 technical understanding 04:35 or just subscribe to my channel i will 04:38 be sure to cover it as soon as it's 04:39 released 04:40 please leave a like if you went this far 04:42 in the video and since there's over 80 04:45 percent of you guys that are not 04:46 subscribed yet 04:47 consider subscribing to the channel to 04:49 not miss any further news 04:51 thank you for watching

Introducing DALL·E: Inspired by GPT-3 and Image-GPT from OpenAI

We all have names for everything – our cats, dogs and maybe even that cow we are about to kill. But how come we do not name our CSS codes? The sad thing is that so many programmers and developers tend not to name the CSS codebase they are using. This does not mean that their programs won’t work but imagine one of the websites or software you are developing has a bug at someplace after you have done a lot of work. If you do not name your codes, it would be difficult for you to debug it. And debugging in that kind of situation is very difficult. This is because you can make some errors while debugging that can become bugs in themselves. This is unsustainable on the long run and you may find yourself having to run the whole code again just to fix a single bug. The way to avoid this is to name your CSS codebase. This way you could quickly make modifications to the codes using the name and not have to do much tampering with your codebase. This prevents errors which may further complicate debugging. The way to do this is by using the system of block element modifiers. In summary, proper naming of your codebase prepares you for making corrective adjustments to your website later on. We are going to take a look at the components of the Block Element Modifiers (BEM) individually. The Block: This is the first part of the BEM. It can stand on its own. It is usually the parent name. In simple terms, your codes for a particular class should be named using Blocks. Blocks can interact with each other but they do not supersede each other. They are independent and can stand on their own. Block names could be in Latin letters, digits and dashes. To make it a CSS class, you have to add the block as a short prefix for name spacing. For example, if you want to name your code with a block, you would use something like “.name”. Let’s say for example I want to make a code and I want the code to be named cups in CSS, I would add the block: { }

( { }) .cups .block Example: < = > button class ”btn” </ > button < > style { } .btn </ > style The Element: Great! we have given our codebase a name. Now we want to add other variables that are dependent on the block. We can do this by adding an element. An element is a child of the block. That is the block is higher in the hierarchy than the element and any codebase that is under the element is controlled by the block. Let’s use the block we have added before in CSS named Cups. If we want to add some dependent elements like – let’s say, mugs and tumblers. We can do this by making them children of the block which in this case is named Cups. Here is how we would write that in CSS – We would have to put two underscores after the block name before we input the elements. Like this: { } { } { } .cups__mugs .cups__tumblers .block__element Example: Look at me! < = > figure class "photo" < = = > img class "photo__img" src "me.jpg" < = > figcaption class "photo__caption" </ > figcaption </ > figure < > { } { } { } </ > style .photo /* Specificity of 10 */ .photo__img /* Specificity of 10 */ .photo__caption /* Specificity of 10 */ style The modifiers: Now we have a block as a name and we have two elements which depend on the block. Now we may need to change the appearance of the block or to change the feature of the block. Adding a modifier to the block will change the block in some way. For example, if we want the cup to be modified by the word “orange” we can add orange as a modifier. We can do this by adding two hyphens in front of the block name (cups in this case) and then add the modifier which is orange. An example of this in CSS is: { } { } .cups--orange .block--modifiers If we want to add another modifier like say “hidden” we can type in the code { } .cups--hidden We can also decide to use modifiers to alter the elements in my block. For example, let’s say we want to give our mug an attribute of orange, we can enter a CSS code like this: { } { } .cups--orange .cups__mug .block--modifiers .block__element This will make mug take on the attribute of orange which is also an attribute of the block. However, if we want the element to have its own unique attribute let's give it a modification of big. We can enter it this way: { } { } .cup__mug--big .block__element--modifiers More examples: < = > button class "btn btn--secondary" </ > button < > { : inline-block; : blue;
 } { : green;
  }  

</ > style .btn display color .btn--secondary color style Putting it together: We have given you a look at how to add different parts of the Block Element modifier (BEM) separately. But we have to bring everything together so it makes more sense to you. So, if we were to write the BEM at once in CSS it will look something like this: { } { } { } { } { } { } { } .cups .cups__mugs .cups__tumblers .cups--orange .cups--hidden .cups--orange .cups__mug .cups__mug--big Conclusion: What we have done is this, we created a block by the name Cups. We then added two elements which are children of the block which are mug and tumbler. We then modified Cups by giving them the attributes orange and hidden. Next, we modified the element mug so it can express the orange the same way its parent – cups – does. Next, we decided to give the element mug to have its own unique attribute which is “big”. So, in summary, the block which is cups controls the element which is mug and is altered by modifiers like orange and hidden. The modifier orange affects the cups and the mug while hidden affects just the cups. The modifier big affects just the mug. That is the summary of how a block element modifier works.

 CSS Block Element Modifier

An overview of what blockchain forks are and what they mean to the ecosystem If you are following the crypto news at all, there has been a lot of activity around Bitcoin and various factions of its users who are “forking” the protocol resulting in many different “Bitcoins”: Bitcoin Cash, Bitcoin Gold, (and Bitcoin Silver?) and the upcoming duel for market share between Bitcoin Segwit1x vs Segwit2x. I would like to briefly explain what forking means from the perspective of a blockchain and its users. I’ll conclude with some thoughts on why we are seeing so much forking and explain the tradeoffs inherent in such a decision. In general, cryptocurrencies give us a way to track some shared state between potentially mutually trustless parties. This shared state is usually implemented with a data structure called a blockchain. To review, a data structure in this context is just a particular way to organize binary data; a particular class of consensus algorithms are used along with this type of data structure to get the unique properties of cryptocurrencies. We can break down the word “blockchain” to better understand what is going on here: taken apart, a blockchain is just a “chain” of “blocks”. The chain notion reflects a chain like you see on your bicycle or fence — a series of links that are connected with one link after the other. The blocks here contain cryptocurrency transactions (e.g. “Send 1 BTC to my friend”) and a cryptocurrency transaction should not be considered to have taken place until the computers maintaining the network have all agreed that a transaction should go into a particular block on the chain. This network-wide agreement process gives us a total ordering of individual blocks (each with a batch of transactions) so that we have a single history of activity amongst the cryptocurrency’s users. Having a single history is what lets us avoid issues like double spend because you shouldn’t be able to spend a particular token more than once. This property follows our intuitions around classical money (e.g. fiat cash). A cartoon of some portion of some blockchain follows. We see four blocks that are lettered - . The arrows in the diagram refer to the fact that some data in that block contains a reference to the block it points to. This sequence of references is what gives a blockchain its “chainness” — we can clearly see the “chain of blocks”. The squiggly lines on each block are representative of transactions in that block (e.g. “send 1 BTC from this address to that address”). A D Borrowing some terminology from computer science, we call the block before some block in the blockchain its . The block following a parent block is the parent’s . Here, we can say that block is a child of block and block ’s parent is block . Block is a child of block . parent child B A B A D C An important point to remember here is that the public cryptocurrencies are . This fact means that any computer participating can suggest a new block of transactions. We get a in the chain when multiple computers on the network issue proposals for child blocks that all have the same parent block. A fork can happen for a variety of reasons; some an expected part of operating the blockchain and some considered attacks against the protocol. For example minor forks occur pretty frequently in public systems due to some randomness in timing associated with the protocol — you could honestly think it is your turn to add a new block just because you haven’t yet heard that someone else is actually “first in line” to add the next block. permissionless fork Cryptocurrencies are designed to work this way such that these forks naturally resolve over a nominal amount of time given the consensus rules of the protocol. The opportunity for attack arises when a fork is created that is not resolved via the network consensus. In this case, a malicious actor causes a fork on purpose and now there are two competing histories of what has happened according to the protocol. You can start to see how dangerous this situation is for belief in a cryptocurrency as this malicious actor could issue a transaction on one branch that results in receipt of some expensive good and the same transaction on the other branch actually just sends the funds back to the attacker. If the network decides to accept the alternative branch after the exchange of goods, the seller could have a huge loss on their hands. The way Bitcoin (and other proof-of-work cryptocurrencies) are designed is that it takes a majority of computing power on the network to successfully pull off this kind of attack (a “51% attack”) and as long as there is incentive to apply the majority compute power honestly, the network will remain secure. Let’s explore a double spend attack executed with a 51% attack with another cartoon. which is the road more traveled? We see two orderly blocks, the purple and blue blocks, in this chain until we get to a fork with two choices— the gray and green blocks which are both children of the blue block. Importantly, notice that there are two transactions between the blocks from the same sender (gold line) to two different recipients (blue and red dots). In this situation, it means that some part of the network thinks the next block is the gray one and some other part of the network thinks the next block is the green one. As long as a majority of the computers on the network pick one branch over the other, this fork will be resolved in time and the selected block will be the one that goes into the single consistent history of transactions on the network. Until this agreement has taken place, which transaction is the “correct” one is ambiguous and an attacker can use this to their advantage as just described. To make this attack concrete, consider an attacker who wants to buy a Tesla in Bitcoin. The attacker creates two slightly different transactions that are gold on the diagram above. One transaction sends the Bitcoins to the Tesla dealer’s address represented with the blue dot. The other transaction with the red dot sends the Bitcoins to an address the attacker controls. The attack unfolds when the Tesla dealer is convinced temporarily that the honest transaction has been included in the blockchain and hands over the keys to the car. The attacker then uses their majority weight on the network to indicate that the other block is actually the correct block. If this happens, the Tesla dealer may not have any recourse against the thief. It turns out that changing certain parts of the protocol results in a fork just like in the 51% attack. If you change the types of messages you are using to come to consensus, or you change how you interpret those messages, you are going to get different subsets of the network following different sets of rules — consensus failure by definition. If you follow the stories presented in the media, you will find that different factions of a given cryptocurrency’s users want to add or change some feature (like the size of each block) in some way that is not compatible with the existing protocol. When we have inconsistent messages in the protocol, we get a fork.¹ Offhand you would expect unnecessary forking to be a bad thing — and you would be correct. If lasting forks were common, then it would be very hard to use blockchains to represent currency as there would be as many different types of currencies as you would have forks. An overly forked chain could not give us a record of a store-of-value and this event would reflect a quickly diminishing market cap. This fear is what drives much of the anxiety around forks: a bad fork greatly threatens the legitimacy of your chain. This danger is highlighted with Bitcoin which now has a market cap around $100 billion USD. Serious amounts of capital is at risk and has driven the press coverage mentioned earlier. The alternative — to make no change or very slow change — is not particularly viable either as it holds back the continued adoption of the currency whether due to scalability limits or lack of features offered to users in other chains. This tension between experimentation and conservatism drives the debates around whether to fork or not. So what can we do? We should acknowledge it can be very risky to introduce a new feature into a cryptocurrency due to a risk of consensus failure from some bug in your upgraded code. This risk slows down experimentation with new blockchain features and elevates the rate of accumulation of technical debt for a given cryptocurrency project. At the end of the day, a fork for the right reasons may be a good thing for a given cryptocurrency and this rationale is supporting the teams forking Bitcoin and producing all of the cloned currencies you have been hearing about. The ability of blockchains to organize humans across space and time is a paradigm shift in technology and it is too early to say that we have found the final answer to a public chain already. Accordingly, experimentation is a highly desired outcome and forking is currently the best tool we have to tackle this problem. If we commit to move in unison as a community we will be able to survive a bad fork and be able to continue to build towards what comes after. Until next time, fork on! 1: There is a technical distinction to make here between and forks. A fork is a fork where each branch has a conflicting set of rules so that users have to choose one branch or the other. A fork is named in analogy and refers to a change that adds some extra feature but still remains compatible with users who do not upgrade to the new rule set. hard soft hard soft

What the fork? A tale of many chains.

In this post I discuss what I learned after seven months of organizing one of the largest cryptocurrency developer meetups in the heart of Silicon Valley — specifically I discuss three lessons, shedding insight on how we overcame the most significant obstacle faced by meetups, oss, and blockchain projects: building a community. My very first event — Zcash 1/24/18 An AR fashion enthusiast, a charismatic entrepreneur, and a college student walk into a bar. No, that’s not the beginning of a bad joke, its a typical Wednesday night — a night filled with the laughter, chatter, speculation, and excitement following a technical deep dive into yet another exciting application of technology. Over my seven month campaign as co-organizer of the SF group, I had the privilege of leading these events, every other Wednesday, sometimes even three or four weeks in a row. No matter what the topic, I always ended up awake, late into the hours of Thursday morning, deep down the rabbit hole of trying to understand the and ? blockchain Crypto Devs Meetup How to Contribute to Bitcoin Core, Cross-chain Atomic Swaps, or Discreet Log Contracts, why how Alas this all came to an end this past Tuesday night as I handed off the baton to my successor, the wonderful Val Mack, in preparation for my return to Colby College where I will finish my undergrad (two years left, oh my!). So tonight, I sat down and pondered on my experience, the successful events, forgetting to order pizza, Mark Nadal’s neon green pants, and launching Block and Jerry’s. In doing so, one common theme stood out. Community, the life and death of meetups, oss projects, and the entirety of the blockchain space. The following are three stories, demonstrating lessons I learned on how to build an engaged, active, and enthusiastic community. Hack and Chat Sundays How do you make an open source project appealing? What excites a bored engineer and inspires the effort of opening a PR? Those are some of the questions I pondered as I attempted to create my own open source community. JZcash For the first three months of my time with SF Crypto Devs, I led the Hack and Chat Sunday events, one or two Sundays per month. The premise of these events was Ultimately, we wanted to foster a community of builders, developing exciting open source software that flourished into the next exciting blockchain project. we provide the coffee, you bring the projects, together we hack. The most amazing group of dedicated people showed up, giving up there Sunday to hack around with us. It was great! Over the course of these weekend events, I attempted to bootstrap a spectrum of (failed) projects: JZCash A Documentation of the Parity Bitcoin Client A JavaScript Telegram Bot A Rust Meetup Bot These first attempts to build something and attract a dedicated community of contributors failed — while they all started with great intentions, people stepped in and made a few contributions and we all learned a thing or two, the excitement didn’t last. Eventually development came to a halt and the community dispersed. However, we did eventually strike gold. Me holding the satellite dish in place. One especially bright and sunny Sunday afternoon, on the roof of the Galvanize workspace, a group of SF Crypto Dev engineers worked together to construct a receiver. We had a python professional debugging the gui software, an embedded systems expert explaining how I bought the wrong parts, three of us continuously repositioning the dish, and the rest working through the set (the only set) of instructions we could find. Blockstream Bitcoin satellite Six hours later our reservation ran out and we had to pack up. While we were not able to properly align and configure the receiver, the camaraderie and team work was unparalleled; the community present on that day still occasionally reminisce on that experience — if we just had the right parts and if we had tried moving the receiver an extra degree north, we might have succeeded. Lesson #1: In the world of abundant oss opportunities and developer challenges with rewards, people are most excited by unique and challenging experiences, specifically memorably challenges they can tell their friends and family about. Certainly much cooler than or How cool is it to say you hacked around with a Bitcoin satellite receiver? “I won $100 building yet-another chatbot” “I made another trivial contribution to X open source project.” Emergency Readings One Thursday afternoon, Taariq excitedly posted a link with the following caption: Check this out! It is the new Hotness! Avalanche, DAGS! 🔥🔥 He was of course talking about Team Rocket’s recently published whitepaper, titled: Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies Rob, we need an event ASAP. How about we host a reading session to discuss this. We will call it an Emergency Reading and it will be this Sunday from 5PM to 7PM. And just like that, Emergency Sunday readings became a bi-weekly Sunday event (my favorite event, socratic style, interactive discussions of the latest and greatest upcoming cryptography schemes, consensus protocols, etc.) Pretty quickly we had a regular crowd, a dedicated community of people who voluntarily gave up their Sunday, every other weekend, to nerd-out with Taariq and myself. This seemingly came out of nowhere and ultimately made no-sense, at first. Why was a Sunday reading event so exciting? What inspired this dedicated bunch? What incentivized these engineers to spend time during the week, pre-reading, in preparation for the Sunday events? The Pareto principle is real. 80% of what I learned over the course of hosting this Meetup happened at 20% of the events (Sunday Emergency Readings). Of those events, 80% of the contributions came from 20% of the people. Let’s call these people stallions. TLDR: Bear with me, I have a point. At the end of the day, most groups need some sort of leader, someone to push the group forward and to ward against laziness, inactivity, and complacency. Every time we had one of these Emergency Readings, a leader naturally took charge and bestowed upon the group his/her expertise in the subject. For , a distributed systems engineer explained how everything connected together. Avalanche For , I explained the elliptic curve cryptography behind blinded transactions and Pedersen commitments. Mimble Wimble For , Taariq explained his own project’s signature scheme. threshold, proxy re-signatures For , Quinten Le Sceller explained the Dandelion protocol. Grin The experience of the group, and ultimately the success of the event could be credited to the exceptional efforts of a single individual. Lesson #2: Find your stallion. Every community needs someone to push the group forward. The Perfect, Patented, Pizza Formula You simply can’t run a Meetup without pizza. It was the morning of another event and I was faced with the infamous Meetup dilemma, For those unfamiliar with organizing events, this is a non-trivial problem; order too much pizza and it seems like the event is under-booked, order too little pizza and people can’t focus because of empty stomachs. And there is not a one-size fits all solution; ordering pizza is dependent on a number of factors such as the number of RSVP’s, the size of the pizza, and the choice of the restaurant. how much pizza should I order? It took me a while to master this challenge. One time I ordered from Patxi’s to discover their pizzas are small and come in six slices — everyone who showed up after the first ten attendees was underwhelmed. The next time I order ten extra-large pizzas from SOMA pizza for an audience of fifty. I end up taking two whole pizzas back to my apartment (cold veggie pizza for breakfast, lunch, and dinner, yum!). After numerous failures (and reprimanding from Nelly), I eventually figured it out. Here, is the official SF Crypto Devs, patented, precise, formally verified, pizza ordering formula written in rust (proven only under the non-random oracle assumption, aka only works for ).: SOMA pizza fn calc_number_of_pies(rsvps: u32) -> u32 {let number_of_attendees = (rsvps as f32) * 0.33;let number_of_slices = number_of_attendees * 2.0;let number_of_pies = number_of_slices / 8.0;// Don't forget the extra large constant factorreturn (number_of_pies * 0.8).round() as u32;} if you want to test this tool for your event. Here it is on rust playground Bottom line, we have had the perfect amount of pizza for our last five events. A similar story is true for most other aspects of the SF Crypto Dev meetup: Sunday events (as described above), community mailers, the SF Crypto Devs intro slide deck, etc. Everything took time to fine tune. However, once that goldilocks, just right combination was found, it worked (aka find that product market fit — yes, your Meetup is a product that people pay for with their time). Lesson #3: Keep experimenting. A single, failed event , or an unpopular idea says nothing about the community as a whole. Communities are built over time and may take a while to find their stride. Conclusion Chaat Corner was always a favorite! First and foremost, I want to thank the incredible SF Crypto Devs community! I had a truly wonderful time meeting everyone and can’t wait to come back this winter for an event! To you, reading this article. Thanks for letting me share this experience with you — if you are considering starting your own community, go for it! I hope one, or all of these lessons help you find success.

Block Green

block.green

-- employees

Since n.d.

COMPANY RANKING

BLOCK GREEN

EVERGREEN INDEX #2354

Block Green WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

Block Green

block.green

-- employees

Since n.d.

COMPANY RANKING

BLOCK GREEN

EVERGREEN INDEX #2354

RELATED COMPANIESRANK

STORIES ABOUT BLOCK GREEN

Block Green WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!