Working through BUIDL Bootcamp: ECDSA Coin

Overview of Lesson

In my opinion, this lesson makes a lot of sense once you finish it. You’re kept a little bit in the dark while working through it, and even at the end, you can be a little confused about what is going on.

The fundamental thought of this lesson is this: We’re building a coin that can only be issued by using our “Bank Private Key”.

Next, we’ll build a validate function. This checks all the transfers in the list, to see if anyone wrongly executed the Transfer class.

This is an important function to run, because you can still use a coin that is wrongly transferred, and transfer it yourself. But, if you know the coin is stolen, you know it is not under valid ownership, therefore you should probably just leave it alone.

I would recommend playing around with the procedurally written code towards the end of the lesson, when we’re transferring the coin between Alice and Bob. Try and write a function that encapsulates the logic and still returns valid. I tried, and it kept throwing errors, but I had a better understanding of what I was doing and how the coin worked.

Notes: Overview of Digital Signatures

We generate a random number, called p. This is the private key.

We have a pair of huge numbers called G. We use special multiplications p * G. This returns our public key.

This special multiplication is called elliptic curve multiplication. It make sure that people cannot easily solve for our private key.

Signing a Message

If we wanted to sign a message, with our private key, we would:

  • generate R
  • Perform calculation to produce S

This calculation shows that we have possession of our private key, through a derivation.

However, this does not “show” the private key.

Overview of ECDSACoin

Key Structure:

We create the coin from the bank. Then we transfer to a particular person.

We write a function called issue():

def issue(public_key):
    message = serialize(public_key)

    signature = bank_private_key.sign(message)
    transfer = Transfer(
    coin = ECDSACoin([transfer])
    return coin

The important part here, is passing in the public key. This allows us to issue it to a particular person.


We want to make sure that every coin is issued from the bank. If it is not issued from our bank, we need to throw an error.

We write a function called validate():

def validate(coin):
    transfer = coin.transfers[0]
    message = serialize(transfer.public_key)
    bank_public_key.verify(transfer.signature, message)

The Narrative Trap

We think of our life as a narrative. It’s easy to write a story about ourselves.

But our life is not a narrative.

When we get too committed to our narrative we make bad decisions, because we mistook our story for a fortune telling.

If you write a story with your life, you’re doing it wrong.

If you run after created narratives (think Steve Jobs), in order to become a hero, you’re doing it wrong.

Becoming your hero does not mean mindlessly copying them.

Your hero exists because what they do is a natural extension of themselves.

So, become like your hero.

Pursue the things you love. Pursue the things you are naturally attracted towards. If you are like your hero, you will excel and be deemed worthy of hero status.

The narrative trap is baited with delusion mixed with inspiration. It produces confusion with anyone it entraps.

Choose creation and self-expression. You’ll be much happier.

Working through BUIDL Bootcamp: PNG Coin

Fungibility means every coin is the same, or interchangeable.
Definition: In economics, fungibility is the property of a good or a commodity whose individual units are essentially interchangeable, and each of its parts is indistinguishable from another part.

We serialize the coins, because this is how we would transfer the data over the network.

Serialization is the process of converting data into a binary format.

In this lesson we learned:

  • Coins can be created.
  • Coins need to be validated.
  • Coins can be written to disk.
  • We understand how to make Coins, pass them as transfers to our class PNGCoin, validate those transfers, then write coins to disk.

Introduction to AJAX

History of AJAX

The pre-history to AJAX was a technology called “Livescript” developed by Netscape. This allowed users to interact with the browser using small scripts, a precursor to JavaScript.

Later a pseudo-asynchronous method was developed, using iFrames in order to change the content of a page, once it had been loaded and was termed “remote scripting”.

After the dotcom bubble, Microsoft added an API called IXMLHTTPRequest to Outlook Web Access which functions as an HTTP client for JavaScript. This allows the browser to download data, even after the page has been loaded.

Safari soon added support for this method in their 1.2 version of the browser, seemingly in response to the use of it within a social networking website called Orkut which allowed you to rate friends using a star system that was implemented in XMLHttpRequest.

The popularization of this method was caused by Jesse Garret, when he wrote a popular article entitled: Ajax: A New Approach to Web Applications, in which he coined the term AJAX.

The best early implementation of this technology came with the introduction of Gmail, which allowed asynchronous retrieval of email, which to that point had not existed within an email client.

Until recently, the main way to initiate asynchronous data retrieval was XMLHttpRequest, but with the recent introduction of ES6, we now have the Fetch API. Now we’re able to request data asynchronously using multiple methods.

Defining AJAX

Working with AJAX can be intimidating. When I first began to need to incorporate AJAX functionality within an application, I was a little nervous at first. It seemed as if there was a multitude of different definitions, and no one seemed to break them down easily enough. Let’s attempt to break down the various definitions surrounding AJAX.


AJAX stands for Asynchronous Javascript And XML. It doesn’t describe a single technology, rather a range of technologies that are used to asynchronously communicate with the server. A more accurate acronym today would be AJAJ (but is rarely used), substituting JSON for XML.

However, AJAX is the dominant and more recognized acronym, so people tend to use AJAX instead.


JSON stands for Javascript Standard Notation which is an easy and modern approach to encoding data. It was created in 2002 by Douglas Crockford (ever heard of him?) as an alternative to XML

According to, the main two ways JSON is structured is:
(a) by collection of name/value pairs
(b) an ordered list values.

Collection of name/values pairs is look a lot like:

{ "hello" : "world", "testing": "values" }

If you are unfamiliar with value pairs, you can copy this code, open the
browser console (CTRL + SHIFT + I on Chrome) and type var example = and paste in the code.

JSON is essentially written in the same structure as a JavaScript object, so you can type something like example.hello and it will return "world".

The second way JSON is structured is an ordered list of values. That essentially is just a JavaScript array, and is structured like this:

{ "testing" : [1,2,3,4,5,6]}

You can copy this too into the browser console, assign it a variable and work with it, almost exactly like a JavaScript array.

These two concepts can be combined, of course. You can write something similar to:

{ "hello": [1,2,3, "testing"], "blue": "is the best color" }

and it will be considered valid JSON.

To play around more with JSON, this is a great tool to learn what is valid and invalid.


XML is an alternative standard to JSON. It stands for Extensible Markup Language and was created in 1996 as a standard for data encoding.

XML lost out to JSON for a few reasons, including; (1) XML didn’t have the data types JSON had, (2) JSON was easier on a computational level to encode and decode in comparison to XML, (3) JSON was practically built into the web (hyperbole), since JSON is a subset of JavaScript. This makes it much more practical to use JSON.

XML does have advantages such as: metadata, it is renderable by the browser, XML is actually a language which allows for advanced interaction and you can mix data types in XML.

Another big reason why XML lost out to JSON, was the movement from SOAP to REST. We won’t dive deeply into it here, but here is a great indepth article about the history of the movement from SOAP to REST.

XML is structured in a tag like, tree structure. It begins with a declarative statement around the structure, something similar to:

<?xml version="1.0" encoding="UTF-8"?>

Unlike HTML, it doesn’t have a set of tags that are required for the browser to interpret. Instead, you can make up your own set of tags to describe the data that is encoded within the XML similar to:


If you’re interested in playing with XML, this online XML validator is a great tool to learning and messing around with XML.


XMLHttpRequest(XHR) is an API that allows asynchronous communications from the browser to the server.


The Fetch API was integrated within ES6 and allows us another interface to communicate with the server asynchronously.

How AJAX Works

The following is an image that details how AJAX works from a graphical presentation. We’ll break this image down further into individual parts and describe them to you, so that you have a strong understanding of how AJAX functionality works from an implementation standpoint.

A description of how AJAX works

Step 1: Client Side – User interacts with the DOM

The first step in AJAX is the user interaction with the DOM. This can be a button click, an infinite scroll mechanism, lazy-loading images or any type of interaction with the browser that requests data from the server, without the page refreshing.

Typically, you will attach an event listener to a particular node in the DOM and send the asynchronous request when the event is triggered.

Step 2: Web Communication – An Asynchronous Web Request is Sent

After the user interacts with the DOM and an event listener is triggered, either an XMLHttpRequest or Fetch request is sent to the server.

You can send data along with the web request, including values to validate or user entered data (think a form submission with user input), to the server side.

Step 3: Server Side – Server Receives Asynchronous Request

Finally, the server side receives the request and data from the client side. You can begin processing the data, and formatting a response based off of the data sent along with the response.

Step 4: Server Side – Server sends back data

You can now begin to send back data from the request. Continuing our form example, if there was an error, it can be encoded in a JSON value pair:

{"error" : true }

or string/raw data:


or XML

<?xml version='1.0' encoding='UTF-8'?>

Step 5: Web Communication – Response from Server

The browser then receives the data from the server and processes it. Typically the response is processed by the Javascript, converted from JSON or XML and interpreted.

Step 6: Client Side – User Informed

Finally the client side is updated with a response. Sticking with our example, if there was an error response from the form, the page will update displaying with an error. If the submission was a success, we can update with a success message.

Brief Introduction to PushState in WordPress

Yesterday, I was developing a WordPress website and I needed to incorporate PushState in order to properly fulfill particular specifications.

I think it took me a lot longer than I needed, partially because I didn’t come across any easy documentation to understand how to work with PushState. So, consider this an introductory guide to using PushState.

What is PushState?

PushState is DOM function that allows us to change the history of a browser and changes the URL on call.

If you open the console right now and type:

history.pushState({}, "page 2", "bar.html"); 

You’ll see the URL change to https://samuelpedraza/programming/wordpress-pushstate/bar.html

Neat huh? Let’s break down the function:

If you type history in the browser, it’ll show you a snapshot of where you’ve been and a few attributes like the length, state, and so forth.

When you execute history.pushState({}, "", "/bar.html"), it will essentially push whatever elements you include, into this History object.

Our first parameter in history.pushState is {}, which is an empty object. You can pass a value pair into the object, similar to { a : "b"}, execute pushState in the browser, and then type history.state to note that the state is indeed {a : “b”}.

The second parameter is the title of the webpage. However, this isn’t supported by Mozilla and seems to be overall discouraged in using.

The third parameter is fairly obvious, being the URL that you want to set.

Using PushState

Now it the fun part, where we actually incorporate PushState within an application.

First, check out this repository and clone it to your local computer or copy the code to an instance on This is the theme that we will use in order to demonstrate PushState.

Next, go to whatever WordPress instance you are running and create posts with the categories “fruit”, “cars”, and “animals”. Assign three posts per category.

Let’s go file by file with an explanation of how it all fits together, and then we’ll demo it.


Well, every theme needs a style.css file.


For the individual posts.


In this script, we grab all the radio buttons, and iterate through them, setting an eventlistener to execute our ugly function display_data on click.

Our display_data contains the bulk of the logic in our application. Let’s examine it now:

var get_data = this.value
history.pushState({page: get_data}, "", window.origin + "/" + get_data);

The first this we do is check to see if the radio button is checked, and if it is, then we grab the value of the radio button. Next, we execute the pushState function, changing the URL and passing the page data into the history object.

Note: We use window.origin in order to replace the entire URL. We don’t want to append over and over to the end of a URL.

var data = {
  action: "fetch_categories_post",
  category_slug: get_data

Next we prepare for the ajax post event by creating an object with an action field and a POST field of category_slug

// clear html
 // initialize variable
 var information = "";

We then clear out the #element area, and initialize an empty string variable. + "/wp-admin/admin-ajax.php", data, function(response){
	// get response and parse
	response = JSON.parse(response);

	// prepare to display links
	for(var response_iterate = 0; response_iterate < response.length; response_iterate++){
		information += "<a href='/" + get_data + "/" + response[response_iterate].post_name + "'>" + response[response_iterate].post_title + "</a> <br>";

	// display links

This is the last bulk of logic for our application. We post the data to the functions.php, get the response back, parse the response and then compile it into raw HTML, that we then append to webpage.

We then attach this function to the window “load” event, so we can display the proper links when the page is loaded.

Index.php & Categories.php

The index.php and categories.php webpage are very similarly structured.

 <?php wp_head(); ?>
 	<div class="form-group">
 			<input type="radio" name="display_cat" value="fruit" class="form-control" <?php $term = get_queried_object(); if($term->slug === "fruit"){ echo "checked"; } ?>>	
 	<div class="form-group">
 			<input type="radio" name="display_cat" value="cars" class="form-control" <?php $term = get_queried_object(); if($term->slug === "cars"){ echo "checked"; } ?>>
 	<div class="form-group">
 			<input type="radio" name="display_cat" value="animals" class="form-control" <?php $term = get_queried_object(); if($term->slug === "animals"){ echo "checked"; } ?>>
 <div id="element">

 <?php wp_footer(); ?>

This code is from the categories.php page. If the URL is animals, for example, the radio box will be checked.

When the webpage is loaded, the proper posts associated with that category, are then displayed.

The index.php page is almost exactly similar, but without the if statement, that checks for the URL of the page.


The Functions.php is a very straightforward file. We register the main.js file, and then we have a function to process the AJAX request.

function load_js(){
     wp_enqueue_script('jquery', '', '', '', TRUE);
     wp_enqueue_script('mainJS', get_template_directory_uri() . '/main.js', '', '', TRUE);
add_action('wp_enqueue_scripts', 'load_js');

Pretty straightforward code, registering the JavaScript and jQuery.

function fetch_categories(){
   $cat_slug = $_POST['category_slug'];

   $cat_posts = get_posts('category=' . get_cat_ID($cat_slug));

   echo json_encode($cat_posts);

This is fairly straightforward code. We get the POST request from the JS file, grab each post from the category, JSON encode it, and then send it back to the main.js file.


Overall, we’ve seen how to assemble a basic example of using PushState. We can grab and display different posts, without refreshing the entire page, while allowing the page to have indexable content.

Bitcoin & Protocol

Bitcoin is going to be a protocol.

Bitcoin is not currently a protocol.

Bitcoin is like the Internet. The Internet has 8 layers of infrastructure, that let you go on FaceBook. But it didn’t start with 8 layers.

Bitcoin has 1 ½ layers. The blockchain, and maybe Lightning Network.

We have to wait and see what Bitcoin layers on-top of itself. Then it will be very useable.

People don’t know what TCP/IP is or does. Perhaps people will barely know what Bitcoin is or does.

Programmer vs Engineer

Lately I’ve been diving deep into the fundamentals.

One thing I was quite interested in, was the underlying architecture of Git.

I didn’t understand was quite how Git stored information.

Then, I read about Hash Tables in Four Semesters of Computer Science in 5 hours. It was quite enlightening.

It made me realize the difference between Programmers and Engineers.

Engineers understand the system. Programmers use the system.

Maybe more directly, Engineers can build the system, use the system, critique the system, rewrite the system. Programmers can only use the system.

Breaking Online Status

Status is a pervasive element in our society, and affects our online social media interactions significantly.

Obsession with status, a zero sum game, leads obsessors to feelings of insignificance or adds credence to incorrect information.

We can break social media status symbols through an online marketplace that enables people to pay for likes, follows and retweets from real individuals. Imagine PPC, but instead of FB receiving the money, it is a single individual.

Payment for social status, diminishes the significance of social status, breaking traditional models of judging by status. Individuals are forced to make decisions based off of content, not status.