
Sign up to save your podcasts
Or


Wiki: https://en.wikipedia.org/wiki/Walk_off_the_Earth
- 2011: Someone Like You (5 People 1 Guitar) https://www.youtube.com/watch?v=d9NF2edxy-M
- 2018: Girls Like You https://www.youtube.com/watch?v=e3PcnNiWygw
- 2020: A History of the Beatles https://www.youtube.com/watch?v=rfOx4CmQWLs
From the Psychology Podcast again: https://www.listennotes.com/podcasts/the-psychology-podcast-with-scott-barry-10LF_aSGfEg/#search
Source: https://www.listennotes.com/podcasts/the-psychology-podcast-with-scott-barry-10LF_aSGfEg/#search
Source: https://freakonomics.com/podcast/frbc-robert-cialdini/
Listen to the Pyschology Podcast: https://scottbarrykaufman.com/podcast/robert-cialdini-the-new-psychology-of-persuasion/
Steph Smith's book:
## Social Proof
The next principle is what we call social proof. The idea that one way we decide what we should do in a situation is not proof that comes from some empirical or logic. Uh, information that we've received, it comes from social information. What are the people around us like us doing in this situation that allows me to reduce my uncertainty about what I should.
In this situation. Uh, so, uh, for example, uh, a study done in Beijing shows you the cross-cultural reach of this, uh, restaurant managers at one string of restaurants, uh, in, in, in China, put a little asterisk next to certain items on their menu. Uh, and each one immediately became, um, 13 to 20%, depending on the idea.
More likely to be purchased. So what did the asterick stand for it? Wasn't what we normally see, which is, this is a specialty of the house, or this is the chef's selection for this evening. It was, this is one of our most popular items and each became 13 to 20% more popular for its popularity. And so. One way as a communicator of genuine information that we can give to other people is to say, we have a lot of popularity for what we are doing and give them examples of that or percentages or market share or this sort of thing.
And that always is, uh, an easy way for people. To take the shortcut to yes. Oh, okay. Then I don't have to continue to calibrate it. Yeah. And, and, and, and, uh, thinking about the pros and cons of this, the majority of people like me like it. So that's a shortcut. Yes.
But there's some new research. Now, my team is responsible for some of it that takes the principle of social proof to a nother level. And. It is that suppose you have a startup or you have a new product or service or an idea, a new initiative, you would like people to, to join you in. But because it's new, you can't point to social proof. The social proof is minimal. I mean, it's actually negative that a lot of people are doing it.
Is there anything you can do under those circumstances? It turns out it is. Even if you don't have, even if you only have a minority or a small minority of people who have adopted it, because it's a good idea, you have to have a good idea. But if it's a good idea, you get the show, a trim who that minority position, if it's only 20% of the market, that's interested in the, if you just say 20%, that's a statistic. If six months ago, it was 10%. That's a difference and that's much better.
But if you say six months ago, what was 10%? Three months ago, it was 15% this month. It's 20%. The same 20% is the end point of a trend.
And people project the function of a trend into the future. So that for the first time you have the leverage of something, we didn't know the label of before future social proof in the research that we did that showed that if you give people a trend to 20%,
They are more likely to say yes to it, right?
Because they expect in the future, it will be more than 20%.
If you've got a good idea with that kind of ability to move people upward in a trend, you'd be a fool of the influence process. Not the honestly, give them three. Data points. One data point is a statistic, two data points, a difference, three data points, a trend.
## Scarcity
People want more of those things they can have less of. And, uh, w one reason that is the case, I think applies to, uh, what Daniel condoms. It has won the Nobel prize for demonstrating. And that is the power of loss aversion, uh, as opposed to, so that we are more in his prospect theory, says the prospects of losing something are more motivating to us than the prospects of gaining that same thing under conditions of risk and uncertainty.
Yeah. You know, I was on a, uh, at a conference where, um, I was in a program to be interviewed, uh, with, uh, Richard Thaler and Daniel Kahneman. And me. Right. And I said to the interviewer, you know, I feel like I'm in a Nobel Laureate sandwich.
I'm the lettuce. That's hilarious. I mean, those are big hitters. Those are, those are big hitters. Uh, anyway. Yeah. Yeah, so, Hey, thank you. But, uh, what Kahneman says is this loss aversion, well, that's what scarcity, the basis of scarcity is your F if something is scarce or rare or dwindling and available availability, you're afraid that it will be lost to you.
And so, yeah. That's the reason people want those things, uh, that have those characteristics. And, uh, there was a study done of, um, 6,700 E commerce websites. And they looked at AB tests within them to see, which were the factors that if they included it or withdrew, it had the made the biggest difference.
In, uh, conversion from, uh, prospect to customer, it was scarcity. Here's the thing. If you could honestly say that the, we have a limited number of these at this price or with these features or with this payment plan or whatever it was, um, you got significantly more, um, uh, Conversions than any other feature they looked at at 29 of them, by the way, the next five where the other principles of influence nice that scarcity was at the top of those principles provided that it was scarcity of number, not scarcity of not limited time. So it was a limited number of items.
Rather than, oh, you can only get this for a one week. If you can get it for one week, that means you can decide to get it any time in that week. If it's a limited number and there's competition for it, therefore you better move now. And that's the reason limited number is more successful in limited time off.
Listen to the Jordan Harbinger Show: https://www.jordanharbinger.com/robert-cialdini-a-new-look-at-the-science-of-influence/
Sources:
- Back to the Future: https://www.youtube.com/watch?v=e8TZbze72Bc
- Predator: https://www.youtube.com/watch?v=_Z4ll94hN_E
- Death Becomes Her: https://www.youtube.com/watch?v=YsKDxRrscg4
- Forrest Gump: https://www.youtube.com/watch?v=FcOt6mfjxeA
- Captain America: https://www.youtube.com/watch?v=qrXwAeJ87Bk
- Avengers: https://www.youtube.com/watch?v=J1VgF9ysbM8
- Avengers Infinity War: https://www.youtube.com/watch?v=GY4mGgfc0Ag
- Avengers Endgame (Portals): https://www.youtube.com/watch?v=F_mhWxOjxp4
Watch Charles' full talk: https://www.youtube.com/watch?v=Ja9D0kpksxw
Apologies for the bad sound, I moved house and lost my microphone for a while. I'll get it back.
Response from a listener (DaveJ on our Discord):
@swyx enjoyed the last mixtape about Cardano. You closed with the same thoughts that I had initially about academic peer review and how it could slow down progress and network building. I was looking at it through the lens of the usual startup advice "ship quickly and iterate to PMF". You might be coming from a different angle. Charles Hoskinson has talked about this before and here is a summary of his points that appealed to me.
1. Proof is in the pudding. Cardano's main competitors are Ethereum and Polkadot. Ethereum has been trying to do PoS a year longer than Cardano, Cardano shipped PoS first despite the fact that they did it through peer review. Polkadot copied Cardano's PoS protocol for their ecosystem. So Cardano's competitors either copied them or took longer to get to market despite the fact that they are following a startup-y "move fast and break things" mentality.
2. Code is law. Rigour is important in a way that you don't usually see in startup-land. Blockchain is immutable. Making unplanned changes is very difficult and recovering from mistakes is often not possible. For this reason, rigour is super important when designing protocols. Having hundreds/thousands of blockchain/math/CS academics read and peer review your paper provides some of that rigour. Also, because of the compositional nature of blockchain protocols, upfront investments tend to compound over time. I now think academic peer review is a net positive for Cardano (against my initial intuitions). Still though, Bitcoin and Eth were around first and have a head start in network building. Perhaps the inflection point has been hit and the winner(s) are already decided. It doesn't feel like that though. It feels like we're only getting started.
Here is the source: https://www.youtube.com/watch?v=CuKhyz280zA&t=2795s
Listen to Software Engineering Daily: https://softwareengineeringdaily.com/2021/04/07/chainlink-connecting-smart-contracts-to-external-data-with-sergey-nazarov/
Transcript
JM: Tell me a little bit more about the data sources for Chainlink. Like how do those
data sources get vetted and how does the data make its way onto the chain?
SN: Right, absolutely. So there're actually two approaches here and I think they're
both important and the flexibility of how you acquire data is important. The first approach is that
you have an oracle network and that oracle network is a collection of nodes that are incentivized
just like blockchain miners and Bitcoin miners are incentivized. Those nodes are incentivized to
go out and get accurate data in order to generate the most accurate, highly reliable result
possible.
In the first version of how data is put into a smart contract, this oracle network of anywhere from
seven to over 30 nodes basically goes to an API at a data provider that is considered a highquality data provider. Often that's determined by users. So users will say, “Hey, we want that data provider.” Chainlink also has a reputation system where we track how well each node, and even more and more now how each data provider is performing. And so better data providers
get to continue selling their data to Chainlink networks, whereas worst data providers are kind of
not as used by node operators because they're either not responsive or not returning the right
results. And so there's actually a reputation system baked into Chainlink, and it's quite
fascinating because the system inherently puts all of the data on chain and generates a lot of
proof about what's going on with the oracles.
In any case, in the first variant of the system you can go to any data provider, you can go to
really any API in the world and you can request from it and you can come to consensus on the
data from that source assuming you can get other sources or you can come to some model of
consensus that the user wants around that data. And that doesn't require the data provider to do
anything, right? So the benefit of this system is that you have a layer of consensus and you
have a lot of proof that the data was acquired from a data provider and the data providers don't
need to change anything about their infrastructure, right? So the data providers just continue to
provide their APIs, operate the way they have always operated and just do what they're
supposed to be doing. This is the system through which a good amount of the data is acquired
and then the data providers are more than happy to sell their data to Chainlink nodes because
it's consumed into these applications which they're all excited about.
The second version is when a data provider runs their own Chainlink node. And what that
basically means is the data provider gets a lightweight signing appliance. They basically get a
lightweight signing application that allows them to connect their APIs internally to their own
official node. And then that node publishes a contract on-chain, and that on-chain contract is a
representation of that data provider. So now there's an on-chain contract that's the
representation of that data providers services. And that on-chain contract gets requests from
other smart contracts for data to be given to them because, once again, a blockchain cannot
talk to an API. A blockchain has to have an oracle to speak with any API in the outside realworld.
And so the second variant is where data providers that are more interested in kind of selling
their data to the blockchain ecosystem or more convinced about that, and we have many data
providers already doing this live. We have data for sports events, weather events, market
events, all kinds of things out in the real-world already live on production with data providers
running their own production nodes. This variant allows you to get data essentially directly from
an official node run by a data provider. It has the benefits of getting data directly from a data
provider running their own node. It has the limitation in that the data provider now has to be able
to make sure that they are properly connected, that their APIs stay up according to the node and
all these other kinds of nuances. The benefit that they get is they are connected to many
different chains all at once. And in reality this variant basically requires the data provider to want
to opt-in to some kind of infrastructure. It requires them to want to say that, “Hey, I want to kind
of run a function in the cloud or I want to run some kind of node myself and I want to make a
technical investment in that.”
What we found so far is that the majority of data providers just want to sell their data to
somebody and they want to provide that to an oracle network that just retrieves their data and
sells that data successfully to a smart contract. There are some data providers that want to run
their own node and we're working with a lot of those, but I think that's something that's going to
evolve more slowly.
[00:16:33] JM: You mentioned this reputation system for how data gets verified as quality. How
does that reputation system work? How do you vet and ensure quality data?
[00:16:45] SN: So once again there's two levels. There's one level of the node operators and
assuring that they're operating properly and then there's the level of the data providers
responding properly. In terms of the node operators, the way that the Chainlink system works is
that node operators are committing to certain service level commitments, right? They're
basically, in many cases, on-chain committing to a certain degree of service. And they're
committing to that because the on-chain activity that they do is immediately public to everybody
as soon as it happens.
So I think the big nuance difference between a reputation system in the web world and a
reputation system in the blockchain world is that data is immediately available publicly. It is
immediately available for people to know that a node did not respond for a certain period of
time. And that lack of response is recorded on-chain immutably for everybody to analyze. And
we actually have multiple ecosystem teams. We have multiple kind of block explorer-like things
and marketplaces that are all able to analyze the same data about both node operators and
data providers.
So basically the way that it looks is that the node operators are expected to perform to a certain
degree on-chain. Those expectations are clear. They are then able to perform, or in some cases
if they're not able to perform, they are not able to stay on that oracle network. And then the data
providers themselves, for the ones that run their own nodes, it becomes pretty clear what their
responses, are and if their responses are often wrong, then you know once again that data
provider and their node might not be used in an aggregation. They might not be applied to that
aggregation.
In the cases where a node operator gets data from a data source, a lot of that data is actually
more internal to the oracle network and that data is something that's in the process of getting
published on chain. So there is a certain amount of insight that node operators have about the
responsiveness of different data providers and different data sources. At this point the reputation
system extends to node operators and to the node operators that are data sources. It will
continue and is already being extended to cover data provi...
Source: https://www.youtube.com/watch?v=XW0QZmtbjvs
Transcript
[00:00:00] swyx: Part two of my cryptocurrency exploration is on scaling blockchains. And I think if metallic is probably the best and most articulate person to talk about this.
[00:00:09] Vitalik Buterin: There's two major paradigms for scaling blockchains. Right? As you said, we are one and layer two. And layer one, basically means, make the blockchain itself, like it capable of, uh, processing more transactions by having some mechanism by which you can do that. Despite the fact that there's a limit to the capacity of each participants in the blockchain.
[00:00:29] And then what you're two says, while we're going to keep the blockchain as. But we're going to create clever protocols that sit on top of the blockchain that still use the blockchain. And it's still kind of inherit things like the security guarantees of a blockchain, but at the same time, a lot of things that are done off chain.
[00:00:45] And so you get more scalability that way. Um, so. In Ethereum, the most popular paradigm for layer two is roll-ups and the most popular paradigm for layer one is charting.
[00:00:54] Lex Fridman: So one way to achieve layer one scaling is to increase the block size, hence the block size wars quote unquote, and a, you actually tweeted something about.
[00:01:06] Uh, people are saying that Vitalik changed his mind about in, he, he went from being a S
[00:01:13] Vitalik Buterin: small. I went from being big to small. Is it big to small?
[00:01:16] Lex Fridman: And, uh, but you said I've been a medium blocker all along. So maybe you can also comment on, on work, on the very basic aspect before we even get to sharding of where you stand.
[00:01:27] Block
[00:01:28] Vitalik Buterin: size debate. Sure. So the way that I think about the trade-off, as I think about it as a trade-off between making it easy to write to the blockchain and making it easy to read the blockchain. Right. So when I say read, I just mean, you know, have a node and actually verify it and make sure that it's correct.
[00:01:43] And all of those things. And then by right. I mean, send transactions. So I think for decentralization, it's, it's important for both of these tasks to be accessible. And I think that they're like about equally important, right? If you have a. Too expensive to read, then everyone will just trust a few people to read for them.
[00:01:59] And then those people can change the rules without anyone else's permission. But if on the other hand it becomes really expensive to write. Then everyone will move on to like basically second layer systems that are incredibly similar. And that takes away from, you know, decentralization and self sovereignty as well.
[00:02:18] So this has been my viewpoints, like pretty much the whole time, right? It's like, you know, you need this balance and going in one direction or the other direction is very unhealthy in the Bitcoin case. Um, basically what happens was that Bitcoin originally. Like at the very beginning, it didn't really have a block size.
[00:02:33] It just had an accidental block size of 32 Meg or oxides limit of 32 megabytes because that just happens to be the limit of the peer-to-peer messages. Um, but then I didn't even know that part. Yeah. But then, um, so Toshi back in 2010 was worried that even 32 megabyte blocks would be too hard to process.
[00:02:51] So he, uh, put the limit down to one megabyte and, you know, I think the. You mean sneaked in there? Yeah. Just like made an update to the Bitcoin software that made blocks bigger than one. I think it's a million bytes invalid. And I think the impression that most people had at the time is that, you know, this is just a temporary safety measure and overtime, you know, as we become more confident in the software, that limit would be like raised some, uh, somewhat.
[00:03:21] Um, but. That then when the actual usage of the blockchain started going up, and then it started going up first to 100 kilobytes per block, then to two 50 kilobytes per block, then to 500 kilobytes per block. Now let me know there started a kind of coming out of the woodworks, this opinion that like, no, that limit should just not be increased.
[00:03:42] And, and, you know, then there are all of these attempts at compromising, right? Um, No first, there was like a proposal for 20 megabyte blocks. Then there was the two for eight proposal, which is, um, a bit ironic because the 2 48 proposals started off being like a small block negotiating position. But then when the big law people came back and said like, Hey, why aren't we aren't we going to do this?
[00:04:05] They're like, oh no, no, no, we don't want them. We don't want the block size increases anymore. Uh, so, you know, there were these two different positions, right? The small blockers, I think they valued one megabyte blocks for two reasons. One is that they just like really, really believe in the importance of being able to read the Chan.
[00:04:22] But two is that a lot of them really believe in maintaining this norm of never hard forking. Right? So the difference between a hard fork and a soft fork is basically that Ian, a soft fork, um, blocks that were. Any block that's valid under the new rules that were still valid under the old rules. So if you have a client that verifies according to the old rules, then you'll still be able to accept the chain that follows the new rules.
[00:04:48] Whereas with a hard fork, like you have to update your code in order to stay on the chain. Uh, huh? They have this belief that it'll soft forks are kind of either less coercive than hard forks, which by the way, I completely disagree with, um, I actually think soft forks are more coercive because like basically they force everyone who disagrees to sort of go along by default.
Rollups
[00:05:11] Vitalik Buterin: So this might be a good time to talk about roll-ups. What
[00:05:13] Lex Fridman: are roll-ups? Okay. Now we're moving into layer
[00:05:16] Vitalik Buterin: two ideas. So the idea behind a roll up is basically that. So instead of. Just publishing transactions directly on chain and having everyone, you know, do all of the checking of those transactions. Um, what you do is you create a system where users send to their transactions to some central party called an aggregator.
[00:05:44] And like, well, theoretically, you could have a system where like the aggregator, so which is arounds or where anyone can be an aggregator. So, you know, it's still like permission to us to send things. Um, then what the aggregator does is. Strip out all of the transaction data that like is not relevant to helping people update the state.
[00:06:03] So when I say the state, this is like, this is a very important, it's kind of technical term from blockchains. I mean like account balances, code, um, like things that are. Memory internal memory of smart contracts. So like basically everything, the blockchain actually has to keep track of it. Right. So ju you're just still put in, um, you take it, oh, these transactions strip out all the data. ...
From the publisher's feed

227,534 Listeners

6,553 Listeners

12,500 Listeners

4,389 Listeners

475 Listeners

1,749 Listeners