Tor and the Silk Road

This lecture was all about Tor and anonymous communication and then briefly talks about the Silk Road. Instead of just looking at the Silk Road, I expanded my view. I’ve been looking at the Whisper protocol which is a communication protocol that allows decentralized apps communicate with each other. In addition, one can use Signal if you’re trying to communicate as well. Irrespective, the lecture gave a good overview on how it can be used.

Questions answered in this Post:

What is anonymous communication?
At a high level, how does a message move in Tor?
How do you hide routing information?
Where does the term “onion network” come from?
What is a hidden service?
Reading recommendations

Anonymous Communication

Here’s a breakdown of the initial communication network. You have a bunch of senders and receives. For a message to get to a recipient, it has to pass through a communication network where multiple parties will propagate the message forward to the recipient.

Similar to how a Mix worked, a sender wants to send a message to a particular recipient but they do not want to be linked. There are adversaries who are considered the threat model. Any edge or node can be considered an attacker. The lecturer claims that there must exist at least one honest sender, communication network path, and recipient though for the message to get sent.

Tor: high level

Now how does Tor allow the message to pass through safely? Tor does this by picking a chain of intermediaries to find the route. The route can be random but it is fixed in the Tor protocol to be 3. The sender will pre-select a path of (3) x intermediaries for how the message will pass. The security guarantee is thus, as long as one of the nodes is not compromised then the sender is safe. By safe, I’m referring to the unlinkability is maintained. There are some attacks on Tor specifically “end to end traffic correlation attack”. People will look at timing to see when the nodes may communicate with each other. One key challenge is how do you hide routing information?

Tor: hiding router information

To send a message, the destination (IP address) has to be present. However, if we think any of the routers are compromised, we do not want the router being able to see the destination. Arvind mentions that the answer is encryption, specifically layered encryption. Layered Encryption resembles an onion which is where the term onion routing comes from. Alice and the first router share a symmetric key. Alice and the second router share another key. Alice and the third router also share a key. The symmetric keys are ephemeral just to be used when needed. The only long term keys are the keys held by the routers where each would have a public key and such. The last leg from the third router to Bob is unencrypted. However up until that point the message is encrypted. As the message passes along the routers, there are layers of keys that gets peeled off which indicates the next place to send it and the encrypted message. If you use secure web browsing of https, you’re able to encrypt the final message to Bob.

Silk Road: Challenges

According to the lecturer, Silk Road was an anonymous market place that sold illicit items and run by Dread Pirate Roberts. Also, the Silk Road was a hidden service. Thus it’s not something you can quick “Google”. To connect you’d need to find a “rendez-vous” point (Tor router) through Tor. Then it will publish the mapping between it’s name and the address of the rendez-vous point. Thus clients can connect to the rendez-vous point and then get access to your website. The addresses are usually random strings of characters and numbers but they end with a .onion address. The closing for this was brief so no nice wrap up, but I’ve listed some readings below.

Reading Recommendations

If you really want to look more into the topic of Silk Road, I have two more recommendation for reading material that I truly enjoyed. The Silk Road portion was usually just portions of the overall books but worth reading the rest of the book as well. I got them both from Overdrive connected to my local library but I’m sure you can also just buy them somewhere too. The first one was Digital Gold. The second one was Dark Net which again really liked. I haven’t gotten to the lecture that they cover the Silk Road and thus I’ll probably recommend that as well.

Zerocoin and Zerocash

Zerocoin and Zerocash and ultimately Zcash

This lecture discusses alternatives to Bitcoin. These coin protocols are not backward compatible with Bitcoin. Zerocoin was initially developed by JHU. From there, Zerocash was created. Zcash is the implementation which is also a fully-fledged currency. Zcoin is similar but based off of Zerocoin. Both protocols provider privacy-preserving version of Bitcoin as part of the protocol. I personally have had experience learning about zero knowledge proofs and Zcash. I was surprised that much of that seems to have been glossed over during the lecture. It’s not an easy topic so hopefully the lecturers maybe spend more time if they decide to expand the series.

Questions answered in this Post:

What is Zerocoin?
What is a zero knowledge proof?
How is a Zerocoin minted versus redeemed?
What is Zerocash?

ZeroCoin

ZeroCoin is a protocol-level mixing. The mixing capability is baked into the protocol. A first version of the paper was released in 2013. Within their abstract they mentioned that Zerocoin, is a cryptographic extension to Bitcoin that augments the protocol to allow for fully anonymous currency transactions. This means that one does not need to trust any user for anonymity, one just needs to trust the underlying protocol. The lecturer brings up another term called BaseCoin to use in the discussion.

Basecoin is defined to be a Bitcoin-like altcoin. Zerocoin is just an extension of Basecoin. So Basecoins can be converted into Zerocoins and back. When they become converted, the link between the old and new coin is broken. This adds that extra layer of anonymity.

Per the lecture, Zerocoin is a cryptographic proof where it relies on you owning an unspendable BaseCoin. Miners can verify that. By having this unspendable coin, you have the right to redeem a new BaseCoin.

Challenges of ZeroCoin addressed

There are two main challenges that the lecturer addresses. The first is who constructs these proofs that guarantees that someone with an unspendable coin can redeem it for a new coin. Also, how do you ensure that it only gets redeemed once. If it got redeemed more than once then you are vulnerable to double spend attacks.

Zero-knowledge proofs (ZKP) are the savior of the day. They provide a way to prove a statement without revealing any other information. Yes, I highlighted most the the sentence because it is that important. You now have the ability to say “I know an input that hashes to some hash in the following set.” You’re able to make these claims without explicitly sharing the input addresses. The talk gets a bit more hand wavy at this point.

Walk through of minting and redeeming ZeroCoin

With ZKP, we can say that ZeroCoins get minted. They come into existence by minting and they come in standard denominations 1 Basecoin == 1 ZeroCoin. Minting a ZeroCoin doesn’t have value. Values results when it gets added to the blockchain. Minting a ZeroCoin is called a “cryptographic commitment”. Intuitively, you’re taking a serial number S that will be put into an envelope. In addition, you generate a random secret r which is never public. From there a hash is generated composed of S (public) and r (private). This sounds very similar to public and private keys being used to generate hashed messages.

With the commitment, you put it onto the blockchain and now it’s part of a transaction. Thus a BaseCoin becomes burned (Minted transaction) and the output has the Hashed serial number and r.

To spend a ZeroCoin S, you now do the reverse. S has to be revealed and miners can verify whether S has been spent before. Next, a zero-knowledge proof is created ie “I know a number r such that H(S, r) is one of the ZeroCoins in the blockchain.” After this crypto-magic, one can pick an arbitrary ZeroCoin in the blockchain and use it as input for the next transaction. Thus, r is not revealed but you can solve this puzzle by knowing of its existence. Someone can look at this and confirm that you have the right to redeem a BaseCoin. The anonymity property is maintained because r is secret and no one can determine which Zerocoin gets linked to the serial number S. Thus ZeroCoin is “efficient” since there is a giant disjunction over all ZeroCoins and yet the time is not linear. They may be slower than Bitcoin but relatively fast. Now we just move towards ZeroCash. It is more efficient using snarks and is not reliant on an intermediary coin like BaseCoin.

ZeroCash

All the transactions can be done in the zero knowledge proof manner because the efficiency has been increased. Zero-cash means untraceable e-cash. All transactions are zero coins and splitting and merging is fully supported. Thus the ledger has a record of the existence of the transaction but only the people who partook in the transaction would know this. Mining fees are kept standard which means very little information is shared. The one issue of the system is that random secret inputs are required to generate public parameters. Thus the secret inputs must be securely destroyed because if anyone knows of them, the system can break. Thus the public keys are like 1 GB in size. There has been coverage regarding this private ceremony. I’ve shared Zcash’s ceremony for some context.
<span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span><span data-mce-type="bookmark" style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" class="mce_SELRES_start"></span>

Here’s NPR’s Radiolab coverage of the same ceremony.

Zcash and Selective Disclosure

I have a few more notes regarding Zcash. I was fortunate to listen to Paige Peterson of the Zcash project speak. As mentioned above, Zcash a fork of Bitcoin. Zcash can be seen as another cryptocurrency that protect the privacy of transactions by using zero knowledge cyptography (ZKP). Zcash has extensions which I thought was interesting like “selective disclosure”. This is the ability that one can authorize 3rd parties to see some pieces of information by giving permissions to it. For me, that allows for a situation where regulators would be more “OK” with the introduction of Zcash because they had the control of the content. the way this occurs is that there is this items called shielded transactions.

I stumbled upon this Zchain blockviewer. This viewer allows you to look at all transaction and there is a section of it that says whether it was Shielded or not. Zcash makes it such that you can remove all input from a transaction and the only piece of information that you would see if the fee. Since the Zcash fee is the same for all, this is really not helpful. However if you are the recipient, Zcash has a mechanism of having viewing keys where it’s a channel so that only intended people can have view access. That’s really neat!

Wrap Up

I’m going to finish this article off with a nice chart that was presented in the lecture titled “5 Levels of Anonymity”.

System	Type	Anonymity Attacks	Deploying
Bitcoin	Pseudo	Tx graph analysis	Default
Single Mix	Mix	Tx graph analysis, bad mix	Usable
Mix Chain	Mix	side channels, bad mix	Bitcoin compatible
Zerocoin	Cryptographic mix	Possible side channels	Altcoin
Zerocash	Untraceable	None	Altcoin

Decentralized Mixing

Last lecture described mixers, but as the lecturer notes there were some flaws with the design. Honestly, this was a dry lecture in terms of the descriptions and content.

Questions answered in this Post:

What are some issues with centralized mixers?
What is CoinJoin?
What are some implementations of CoinJoin?
What is a side channels that the lecturer has alluded to?

Cons for using centralized mixers, pros for decentralized

The lecturer brings up several points. First, there is a inherent bootstrapping problem. For a mixer to be successful and create a large anonymity set, they need to have a large number of users. To get users you need to have a god reputation. This is not the case for decentralized mixers because individuals are banding together. As long as there is sufficient interest, mixing can just occur. Second, there is less trust involved and Arvind mentions that you can guarantee no theft. Dependent on how you structure the decentralized protocol, theft can be prevented. No one user is sending Bitcoins. Also, there may be more anonymity with this method. Lastly, it’s more aligned with Bitcoin given that it is a decentralized method.

CoinJoin

The protocol that does this decentralized mix is called CoinJoin. CoinJoin was developed by Greg Maxwell who is a core Bitcoin developer. Coinjoin is a method for bitcoin transaction compression which aims to improve privacy by discarding unnecessary information. Ok, bitcoinwiki doesn’t really explain too much. Investopedia’s definition is a little better. An anonymization strategy that protects the privacy of users when they conduct transactions and requires multiple parties to sign jointly on an agreement to mix their coins when doing separate Bitcoin transactions.

High level explanation of CoinJoin

According to the lecturer, several users come together for a single Bitcoin transaction, and combines all their inputs (he suggests they should be of equivalent value). All the signatures for each of the inputs are entirely separate so a single user does not have to hold the private keys. This means that the users can have a randomized ordering for the transaction. In addition, this was only a single round of mixing and multiple rounds should take place. So outside users may be able to tell that it is a CoinJoin transactions but will not know the internal specifics. The mixing principles discussed from the previous lecture also need to be used.

More lower level algorithm in a list

Find peers who want to mix (group of like minded people neew to find each other)
Exchange input/output addresses
Construct transaction (only a single person does this)
Send it around, collect signature (Before signing, each peer checks if her output is present: security property)
Broadcast the transactions

Open Questions for CoinJoin

How to find peers?
Arvind suggests using an untrusted server which does add engineering complexity.
Is there a security risk that peers know your input-output mapping?
Arvind mentions that as long as there is diversity in the individuals running nodes, it should be ok. It is possible that a single adversary creates numerous sybils such that every sybil is part of every Coinjoin and thus is able to learn the input-output mapping. Thus this would be a problem that is not present in centralized mixes because those can have reputations. The proposed solutions is just a Strawman solution meaning that it’s just a draft version that people can improve. The proposed solution is disconnecting the inputs and outputs via Tor. That leads to a better solution which is having a special-purpose anonymous routing mechanism. These exist under the special term, Decryption Mixnets.
Can there be denial of service attacks?
Yes, one of the nodes can always choose not to sign the transaction. In addition, someone can remove their coins prior to the Coinjoin transaction being written to the blockchain and thus force a double spend attack. Arvind’s solution is to add some fee to prevent people from doing this arbitrarily. He proposed using proof of work, proof of burn (fidelity bonds), server kicks out malicious participants, or Cryptographic “blame” protocol (Coin Shuffle)

Current Implementation of Coinjoin

What is a side channel, high-level flows?

The example is Alice receiving set bitcoin each week as income and then transferring 5% to a retirement account. This kind of pattern is one that is very visible on a blockchain. To prevent this, Mike Hearn proposed merge avoidance. Thus, a receiver provides multiple output addresses and sender avoids combining the different inputs.

Wrap Up

Which of these is NOT an advantage of Coinjoin over centralized mixes?

Built-in protection against denial-of-service attacks

Mixing: Service to provide de-anonymization

Similar to many solutions to problems in software and computer science, the age old method of “add a layer of indirection”, using an intermediary has been proposed. The point of this lecture was to provide a solution to enable anonymizing the transaction graph analysis discussed in the previous lecture. The takeaway is that online wallets don’t provide any better service than modern banks. This means that people may understand the shift to Bitcoin but it doesn’t really given an advantage to do it. The use of mixing intermediaries can provide anonymity but does require that everyone use them to increase the anonymity set.

Questions answered in this Post:

What is mixing in general?
How does it operate?
What are some other applications that act similarly?
What are the differences between mixing intermediaries and online wallets?
What has happened to certain mixers?
What is Mixcoin?
Why does this model still require trusting mixers?

Mixing

Mixing is one solution to providing de-anonymization by way of introducing an intermediary. Here’s the simple use case. How do you anonymize three people’s transactions that are sending some value to three different counterparties? The visual example (from the lecture) started off with three people sending some value to a single source, the intermediary. From there, the said intermediary would output the same transaction values and send them to the respective addresses as specified from the starting people. The main deal is that the bitcoins are considered “mixed”. Thus you know that three people sent bitcoin and then three entities received bitcoin but you don’t know who sent what. When this scales larger, it becomes more anonymous. Thus someone looking at these transactions would not be able to tie the bitcoin to specific people i.e. removing the inability between the input addresses and output addresses.

How does it operate

A mixer is a service which inputs and outputs certain pieces of information. A mixer will release the address of a mixer (who to send the transaction to). The mixer takes an address for who is receiving the Bitcoin. Mixes make money by charging some fee 1%-3% to handle the transactions. That’s how they make money and in current times, that can add up in price. Thus people shouldn’t mix for small transactions only large ones.

Some issues with mixers

While I think this idea is interesting, my singular thought is the fact centralization is being added. You need to have a mixer that almost everyone uses or else people could see cliques in the network or everyone has their own “cleaner”. I’m not sure if that’s true but that was my understanding of this process. I did some research and found a few mixing services mentioned. The Merkle had an article where they only mentioned four mixers in 2017 and one of the ones mentioned is no longer in service. The reason Bitmixer gave for going dark was posted in a Bitcointalk thread. The tidbit that most articles, here and here, used was “Now I grasped that Bitcoin is transparent non-anonymous system by design.” The rest of the note is worth sharing where he tells users to use Dash or Zerocoin for those dark market transactions.

My second thought was “Isn’t this just straight up money laundering?”. Money laundering is where people move money that was acquired by shady means to make it legitimate by entering certain source. This usually involves real estate, or buying physical items, or just moving money through cash oriented places like laundromats or nail salons. Isn’t this idea of dumping all transactions into one central place pretty much accomplishing that? Apparently others on the internet agreed with me and mentioned that using mixing services may even be illegal for certain country jurisdictions. One red flags for me was that many of the sites on “How to Bitcoin Mix” suggested going to sites via Tor. This lecture didn’t cover that topic here but it’s important so I’ll address it a bit.

Money Laundering is a serious crime that can have reprehensible consequences. It is also how many criminal organizations do their business as well as it has been used to finance terrorist attacks. Organizations that deal with money such as banks, have to deal with federal and international regulations to watch for money laundering. Giving people access to do that in cryptocurrency is making the problem worse. Because of this, it is no surprise that mixing services may be illegal in certain countries and that mixing services are getting more pressure. However, as the lecturer states, this lecture is less on the morals of the actions and just about the pure technology. The lecture then segues into the next topic of online wallets in that they provide a similar service without the anonymity.

Online Wallets: mixing without extra steps?

Right, so he mentions that online wallets provide you the same service. However, most online wallets don’t provide this. The online wallets that I use at least linked an email address to the user accounts. I have used Bitgo before. I have also listed a lot more in my previous post on the online wallets. The online wallets don’t just have to be online wallets. Players like Coinbase and Mt. Gox, ie exchanges also provide this service. Places like Coinbase have zero privacy in that they link people’s real world identities strongly to the Coinbase wallets.

So,what’s the difference?

The lecturer brings up two main points on these mixing services. One they “promise” not to keep records and second they don’t require an identity. These are the main differences since online wallets do the exact opposite. As I mentioned before, they have to keep records of everything because they are regulated businesses. This one article from Townhall posted today highlights some of the areas of taxation for cryptocurrency holders specifically via Coinbase. Some of the tax changes are a result of the recent tax bill passed in the United States. The second point is that users trust these sites and thus will willingly keep their cryptocurrency in these systems longer. That means that there is a larger anonymity set since candidates are willing to keep their coins in these intermediaries longer. The lecturer brings up the point that this is mimicking centralized institutions that exist in current financial institutions. A stranger will only know that perhaps that you’re using this centralized intermediary but will not know your transaction history. The intermediary may keep records of such information but they are not publicly sharing this information. Only regulatory and judicial parties tend to be the ones who are able to request this information. At this point, I don’t have a clear reason why choose bitcoin as a way for more anonymity if you only use online wallets.

Now we just to more of a discussion on mixers. Arvind mentioned that his team studied these mixers and came up with some improvements for them. They proposed them via Mixcoin.

Mixcoin

Mixcoin is the name of the protocol to facilitate anonymous transactions or payments. One recommendation was that they should use a series of mixes, not just one, and there should be a standard API. This is similar to the idea of routers when doing anonymous communication. By having multiple mixes then one is removing that trust of a single mix. The lecturer also showed a visualization where a single users transaction would pass linearly across 3 different mixes before it was finally outputted. Each time the user seems responsible for taking the output and then reinputting the Bitcoin into the next transaction. Because it is being passed through 3 mixes, you need each of them to be honest about how much Bitcoin they are processing and you need to cost of mixing to be low enough that going through 3 mixes doesn’t being too high. Thus the transactions across the different mixer have to look as uniform as possible and thus they may consider having a fixed chunk size. Lastly he mentioned that this mixer works had to be integrated in client side software. Regarding costs, they recommended that fees had to be all or nothing with some probabilistic fee. So in 0.1%, the mixer would have to swallow the cost. This is used to reduce the ability for people to track the mixer via the fees.

While, these are great proposals, mixers have not followed them. They tend to act independently with a web interface (rather than integration in client software). In addition, there is no standard chunk size. The mixer as mentioned above does not use a probabilistic fee.

Why does this model still require trusting mixers?

Mixers still have all the power. You have to trust that they will not just take the input and not return it. Also, when they have a fixed transaction fee, you have to believe them. In addition, you are relying on the mixers to be honest and not keep records and preserve your anonymity. Mixers can improve their reputation by staying in business for long periods of time. However, with this increased reputation, if there are so few mixers, the ones still running have power to charge arbitrary fees. He mentioned something considered cryptographic “warranties”.

Wrap Up

As of now, there is no dedicated mix protocol that everyone follows. It’s also a skewed system that requires trust in the mixer. The Bitcoin wiki says, “Use at your own discretion” as does Arvind.

Which of these techniques can improve the anonymity provided by mixing services?

using a series of mixes
using the same chunk size for all mixing transactions

De-anonymize Bitcoin

How to De-anonymize Bitcoin

Well that’s a funny name for a topic given that the last lecture basically declared that bitcoin was just pseudoanonymous and even then reading through Freedom-to-Thinker posts, it made me think the ecosystem would bank on this fact. The amount of information that can be gleaned if all ecommerce companies use Bitcoin could be an advertiser’s dream. This lecture is once again an overview but substantially shorter than last time.

Questions answered in this Post:

How can all your transactions be linked together?
What is shared addresses?
What does “Idioms of use” mean?
How else can people be de-anonymized?
References to Research Papers from Lecture

Linking all transactions?

The gist of this section is that one can try to prevent having someone link all your transactions by just generating a new address each time. It is easy to recreate a new public key based on your public key. However, it is not unlinkable. If for example the multiple bitcoin from different address get combined together and spent in a single transaction, someone can infer that they are coming from the same private key. Shared spending is then evidence of joint control since the addresses can be linked transitively.

The example given by the research paper is pretty scary. This was done in a paper by Reid and Harrigan, Analysis of Anonymity in the Bitcoin System. The paper combined two networks of both the transaction and user networks from Bitcoin’s public transaction history and were able to investigate a Bitcoin theft that occurred June 2011. Looking at the paper, it’s interesting that they are able to paint a clear story where 60 transaction involving 441.83 BTC were moved on a 70 days period and it total amounted to 25,000 BTC. Based on their analysis, it seems that one is unable to hide or be anonymous in Bitcoin. It is called transaction graph analysis. From the lecturer though, there is some level of probability to determine which address is actually mapped to the user. Thus, this means a second tool is also needed.

“Idioms of Use”

Idioms of use refers to particular features used in wallet software such as each address is used only once as change. This technique was used by Meiklejohn in Fistful of Bitcoin: Characterizing Payments Among Men with No Names. Within their paper, they used two main user heuristics to do account clustering. First was to treat different public keys used as inputs to a single transaction as being controlled by the same user. (This was what the lecturer used in the first case with the tea pot for 8 BTC.) The second was the change addresses tend to be used only once and likely unknown from the actual user. This allowed them to collapse users clusters. Additionally, from 344 transactions to mining pools, wallet services, exchanges, vendors, and gambling sites, they were able to cluster s the main providers/users of the system. From their analysis, they claim that agencies with subpoena power would be capable of determine who is paying money to whom in the Silk Road wallet and other Bitcoin thefts. According to the lecturer, this was a tedious and sometimes manual process. One way to determine owners is that people would self-label them manually in Bitcoin forums. Thus they were able to find the cluster of keys associated with Mt. Gox based on their account clustering.

From these crypto currencies to mapping to real-life identities

Now the lecturer poses another thought of how to find real world users based on their addresses. One could be the self-assigned people who just give up their address in the Bitcoin forum. Likely, if there is a single address posted in the forum, they are not using a new address for every transaction. Also, there is high centralization in service providers meaning that every flow will likely pass through one of them. Thus, as Meiklejohn’s paper mentioned, if someone has the subpoena power, they are able to request from the service provider that actual real-world user identity. However, there is a second layer of information which comes from networking. Specifically, “the first node to inform you of a transaction is probably the source of it”. There is a simpler way to make it more difficult which is just use Tor. Tor is used for low-latency work like just web browsing. Thus the lecturer suggests to use Mix nets, routing protocols that make communication pass through multiple proxies thus breaking a link between the source of a request and the destination. Interestingly, the concept of mix networks also came from David Chaum. Tor is one application of this which is onion routing.

References to Research Papers from Lecture

Wrap-up

Which of the following observations would you suggest that addresses A and B may be controlled by the same user/ entity?

There is a transaction as input addresses.
Combined Shared spending and idioms of use
Coin join works – violates this assumption

Bitcoin Scripts

This is a continuation of the Bitcoin Transaction Basics lecture. I watched the entire third week in one sitting so some of my notes may reference previous posts. This part focuses on “Script” the aptly names bitcoin blockchain scripting language. It’s based on Forth which meant little to me but hopefully means more to others.

Questions answered in this Post:

Why are scripts used instead of just having a public key in transaction outputs?
How do you validate a transaction output?
What is the Pay-to-script hash?
Name at least four characteristics of “Script”.

From the last post, “Each transaction output doesn’t specific a public key, instead it’s a script.” Know that the most import transaction type in Bitcoin is redeeming a previous transaction output by signing it with the correct key. Also, the inputs also contain scripts instead of signature as well.

Output: “Addresses” are really scripts
Simple Script shown has 4 instructions and is called a Pay-to-PubkeyHash.
OP_DUP OP_HASH160 69e02... OP_EQUALVERFIY OP_CHECKSIG
So the input address is also a script that gets combined with the output address
Concat(in.scriptSign | out.scriptPubKey)

scriptPubKey – output script that public key by specifying address to which the public key hashes
scriptSig – signature with that public key.
Together, this lets you claim a public key.

To Verify: Concat script must execute completely with not errors

Bitcoin scripting language(“Script”) History lesson

h5>Build for Bitcoin (inspired by Forth)

simple and compact
support for cryptography (hash function)
stack-based
limits on time/memory
no looping
256 opcodes total(15 disabled, 75 reserved)
logic/datahandling
crypto CHECKMULTISIG
OP_CHECKMULTISIGN
verification requires t signatures

Bitcoin script execution example
This script basically has the sender of the coins specifying the recipient via their public key.

OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG

1,2 does data instructions ie just push it on the stack
OP_DUP take the value on the top of the stack and duplicate
OP_HASH160 taken the crpytographic hash of the top of the stack
push the pubKeyHash? onto the stack
Now we know what comes next, need to verfiy if they are equal and if equal they get consumed
OP_CHECKSIG verify that the signature is valid, makes sure that the full transaction is valid

Steps in how the stack gets read:
1. Just a data instruction to be pushed onto stack

2.Just a data instruction to be pushed onto stack

3. Next call OP_DUP means creates a copy of the top which was pubKey and place on stack

4. OP_HASH160 means hash that key to create hashed_pubKey
5. Next you’re going to push on another intruction which is pubKeyHash
<pubKeyHash?>

6.OP_EQUALVERIFY as you can infer means check if the top two instructions are equal
<pubKeyHash?> == ?

7. Get the result and then does the signature verify by the instuction OP_CHECKSIG

8. Everything else gets taken off

It’s interesting that 99.9% scripts are just a simple signature script

Proof of Burn script

OP_RETURN
script that can never be redeemed
It’s provable that those costs have been destroyed
OP_RETURN throws an error if ever reached
The data comes after it will never be reached

What’s the point of proof of burn

Write arbitrary data into the block chain
like putting your name or timestamp
destroy a very small amount of currency into the block chain

AltCoins way to bootstrap other coins is by destroying bitcoin

Should senders specific scripts?
If a consumer is ready to pay, what do they need to with bitcoin

Me -> I’m ready to pay
Company -> Cool so we have this multisig which means you have to include a script requiring 2 of out 3 account managers to approve. Make sure it’s perfect or it won’t go through

Me -> Yeah, no.

Instead sender can just send a has of the script that needs

Pay to Script Hash instead

Idea: use the hash of redemption script
OP_CHECKSIG

OP_HASH160

OP_EQUAL

Can create a 2 step process
traditional script had right has

redemption hash deserialized and a second check occurs

so you’re removing complexity from the sender and there is an efficiency gain (only need to put a hash) all the rest of the complexity in the script is pushed to the input script.

Since this was added after the fact, it looks kinda a screwy

FYI: This site has more information regarding he scripting language. Also this is the Github.