1
00:00:00,000 --> 00:00:03,440
Greetings and salutations my fellow plebs.

2
00:00:03,440 --> 00:00:07,240
My name is Walker and this is the Bitcoin Podcast.

3
00:00:07,240 --> 00:00:12,920
It's Tuesday, October 31st, 2023, so happy Halloween.

4
00:00:12,920 --> 00:00:21,440
The Bitcoin Block Height is 814-721, and the value of one Bitcoin is still one Bitcoin.

5
00:00:21,440 --> 00:00:25,800
It's also the 15th anniversary of the Bitcoin White Paper.

6
00:00:25,800 --> 00:00:30,360
So for today's Bitcoin Out Loud Read, I'm going to read it for you.

7
00:00:30,360 --> 00:00:35,000
If you're already deep down the Bitcoin rabbit hole, you've probably read it already, or

8
00:00:35,000 --> 00:00:36,720
at least you should have.

9
00:00:36,720 --> 00:00:40,160
So send this to your friends and family instead.

10
00:00:40,160 --> 00:00:45,080
But if you're new to Bitcoin or still just Bitcoin curious, today is your chance to hear

11
00:00:45,080 --> 00:00:49,280
about Bitcoin in Satoshi Nakamoto's own words.

12
00:00:49,280 --> 00:00:55,440
If you want to watch me read the Bitcoin White Paper in my Ken costume, head to Rumble YouTube

13
00:00:55,440 --> 00:00:58,200
or X and search at Walker America.

14
00:00:58,200 --> 00:01:03,000
I have the diagrams available on screen in the video version for your reference as well.

15
00:01:03,000 --> 00:01:08,760
If you're already watching this and you prefer audio, listen on fountain.fm or wherever you

16
00:01:08,760 --> 00:01:12,920
get your podcasts by searching for the Bitcoin Podcast.

17
00:01:12,920 --> 00:01:17,680
And if you listen to the Bitcoin Podcast on fountain, consider giving this show a boost

18
00:01:17,680 --> 00:01:22,800
or creating a clip of something you found interesting so more people can find the show.

19
00:01:22,800 --> 00:01:27,360
For those that have boosted the show already or zapped me on no-ster, thank you.

20
00:01:27,360 --> 00:01:32,880
And if you're a bit coiner and you're not listening to Bitcoin Podcasts on fountain,

21
00:01:32,880 --> 00:01:34,360
what the hell are you doing?

22
00:01:34,360 --> 00:01:44,600
Now without further ado, let's get into this Bitcoin Out Loud Read.

23
00:01:44,600 --> 00:01:50,840
Bitcoin, a peer-to-peer electronic cash system by Satoshi Nakamoto.

24
00:01:50,840 --> 00:01:52,160
Abstract.

25
00:01:52,160 --> 00:01:57,240
A purely peer-to-peer version of electronic cash would allow online payments to be sent

26
00:01:57,240 --> 00:02:02,280
directly from one party to another without going through a financial institution.

27
00:02:02,280 --> 00:02:07,160
Digital signatures provide part of the solution, but the main benefits are lost if a trusted

28
00:02:07,160 --> 00:02:10,640
third party is still required to prevent double spending.

29
00:02:10,640 --> 00:02:16,520
We propose a solution to the double spending problem using a peer-to-peer network.

30
00:02:16,520 --> 00:02:21,920
The network timestamps transactions by hashing them into an ongoing chain of hash-based

31
00:02:21,920 --> 00:02:27,640
proof of work, forming a record that cannot be changed without redoing the proof of work.

32
00:02:27,640 --> 00:02:33,120
The longest chain not only serves as proof of the sequence of events witnessed, but proof

33
00:02:33,120 --> 00:02:36,920
that it came from the largest pool of CPU power.

34
00:02:36,920 --> 00:02:42,200
As long as the majority of CPU power is controlled by nodes that are not cooperating to attack

35
00:02:42,200 --> 00:02:46,920
the network, they'll generate the longest chain and outpace attackers.

36
00:02:46,920 --> 00:02:53,200
The network itself requires minimal structure, messages are broadcast on a best-effort basis,

37
00:02:53,200 --> 00:02:57,600
and nodes can leave and rejoin the network at will, accepting the longest proof-of-work

38
00:02:57,600 --> 00:03:01,760
chain as proof of what happened while they were gone.

39
00:03:01,760 --> 00:03:02,920
1.

40
00:03:02,920 --> 00:03:05,040
Introduction.

41
00:03:05,040 --> 00:03:10,640
Commerce on the Internet has come to rely almost exclusively on financial institutions,

42
00:03:10,640 --> 00:03:15,520
serving as trusted third parties to process electronic payments while the system works

43
00:03:15,520 --> 00:03:20,360
well enough for most transactions, it still suffers from the inherent weaknesses of the

44
00:03:20,360 --> 00:03:21,960
trust-based model.

45
00:03:21,960 --> 00:03:27,120
Completely non-reversible transactions are not really possible, since the financial institutions

46
00:03:27,120 --> 00:03:29,960
cannot avoid mediating disputes.

47
00:03:29,960 --> 00:03:35,840
The cost of mediation increases transaction costs, limiting the minimum practical transaction

48
00:03:35,840 --> 00:03:41,800
size and cutting off the possibility for small, casual transactions, and there is a broader

49
00:03:41,800 --> 00:03:48,680
cost in the loss of the ability to make non-reversible payments for non-reversible services.

50
00:03:48,680 --> 00:03:53,440
With the possibility of reversal, the need for trust spreads.

51
00:03:53,440 --> 00:03:58,160
Merchants must be wary of their customers, hassling them for more information than they

52
00:03:58,160 --> 00:03:59,600
would otherwise need.

53
00:03:59,600 --> 00:04:04,160
A certain percentage of fraud is accepted as unavoidable.

54
00:04:04,160 --> 00:04:10,480
These costs and payment uncertainties can be avoided in person by using physical currency,

55
00:04:10,480 --> 00:04:16,080
but no mechanism exists to make payments over a communications channel without a trusted

56
00:04:16,080 --> 00:04:17,480
third party.

57
00:04:17,480 --> 00:04:24,240
What is needed is an electronic payment system based on cryptographic proof instead of trust,

58
00:04:24,240 --> 00:04:29,720
allowing any two willing parties to transact directly with each other without the need

59
00:04:29,720 --> 00:04:32,480
for a trusted third party.

60
00:04:32,480 --> 00:04:38,000
Transactions that are computationally impractical to reverse would protect sellers from fraud,

61
00:04:38,000 --> 00:04:43,000
and routine escrow mechanisms could easily be implemented to protect buyers.

62
00:04:43,000 --> 00:04:49,200
In this paper, we propose a solution to the double spending problem using a peer-to-peer

63
00:04:49,200 --> 00:04:56,880
distributed timestamp server to generate computational proof of the chronological order of transactions.

64
00:04:56,880 --> 00:05:03,200
The system is secure as long as honest nodes collectively control more CPU power than any

65
00:05:03,200 --> 00:05:06,640
cooperating group of attacker nodes.

66
00:05:06,640 --> 00:05:08,960
2.

67
00:05:08,960 --> 00:05:09,960
Transactions

68
00:05:09,960 --> 00:05:15,000
We define an electronic coin as a chain of digital signatures.

69
00:05:15,000 --> 00:05:19,860
Each owner transfers the coin to the next by digitally signing the hash of the previous

70
00:05:19,860 --> 00:05:26,080
transaction and the public key of the next owner and adding these to the end of the coin.

71
00:05:26,080 --> 00:05:30,760
A payee can verify the signatures to verify the chain of ownership.

72
00:05:30,760 --> 00:05:36,040
The problem, of course, is the payee can't verify that one of the owners did not double

73
00:05:36,040 --> 00:05:37,680
spend the coin.

74
00:05:37,680 --> 00:05:43,280
A common solution is to introduce a trusted central authority, or mint, that checks every

75
00:05:43,280 --> 00:05:45,960
transaction for double spending.

76
00:05:45,960 --> 00:05:51,000
After each transaction, the coin must be returned to the mint to issue a new coin, and only

77
00:05:51,000 --> 00:05:55,800
coins issued directly from the mint are trusted not to be double spent.

78
00:05:55,800 --> 00:06:01,240
The problem with this solution is that the fate of the entire money system depends on

79
00:06:01,240 --> 00:06:03,280
the company running the mint.

80
00:06:03,280 --> 00:06:08,720
With every transaction having to go through them, just like a bank, we need a way for

81
00:06:08,720 --> 00:06:14,840
the payee to know that the previous owners did not sign any earlier transactions.

82
00:06:14,840 --> 00:06:20,000
For our purposes, the earliest transaction is the one that counts, so we don't care

83
00:06:20,000 --> 00:06:22,520
about later attempts to double spend.

84
00:06:22,520 --> 00:06:29,320
The only way to confirm the absence of a transaction is to be aware of all transactions.

85
00:06:29,320 --> 00:06:34,720
In the mint-based model, the mint was aware of all transactions and decided which arrived

86
00:06:34,720 --> 00:06:35,720
first.

87
00:06:35,720 --> 00:06:41,440
To accomplish this without a trusted third party, transactions must be publicly announced,

88
00:06:41,440 --> 00:06:46,360
and we need a system for participants to agree on a single history of the order in which

89
00:06:46,360 --> 00:06:48,000
they were received.

90
00:06:48,000 --> 00:06:53,760
The payee needs proof that at the time of each transaction, the majority of nodes agreed

91
00:06:53,760 --> 00:06:56,520
that it was the first received.

92
00:06:56,520 --> 00:07:03,240
3. Time Stamp Server The solution we propose begins with the Time

93
00:07:03,240 --> 00:07:04,740
Stamp Server.

94
00:07:04,740 --> 00:07:10,240
A Time Stamp Server works by taking a hash of a block of items to be time stamped and

95
00:07:10,240 --> 00:07:15,600
widely publishing the hash, such as in a newspaper or Usenet post.

96
00:07:15,600 --> 00:07:21,280
The time stamp proves that the data must have existed at the time, obviously, in order to

97
00:07:21,280 --> 00:07:23,400
get into the hash.

98
00:07:23,400 --> 00:07:28,880
Each time stamp includes the previous time stamp in its hash, forming a chain, with each

99
00:07:28,880 --> 00:07:34,120
additional time stamp reinforcing the ones before it.

100
00:07:34,120 --> 00:07:38,280
Proof of Work To implement a distributed time stamp server

101
00:07:38,280 --> 00:07:44,080
on a peer-to-peer basis, we will need to use a Proof of Work system similar to Adam

102
00:07:44,080 --> 00:07:49,280
Back's hash cache, rather than newspaper or Usenet posts.

103
00:07:49,280 --> 00:07:56,040
The Proof of Work involves scanning for a value that when hashed, such as with SHA-256,

104
00:07:56,040 --> 00:07:59,280
the hash begins with a number of zero bits.

105
00:07:59,280 --> 00:08:04,520
The average work required is exponential in the number of zero bits required, and can

106
00:08:04,520 --> 00:08:07,720
be verified by executing a single hash.

107
00:08:07,720 --> 00:08:12,880
For our Time Stamp Network, we implement the Proof of Work by incrementing a nonce in the

108
00:08:12,880 --> 00:08:19,640
block until a value is found that gives the block's hash the required zero bits.

109
00:08:19,640 --> 00:08:25,240
Once the CPU effort has been expended to make it satisfy the Proof of Work, the block cannot

110
00:08:25,240 --> 00:08:30,480
be changed without redoing the work, as later blocks are chained after it.

111
00:08:30,480 --> 00:08:35,600
The work to change the block would include redoing all the blocks after it.

112
00:08:35,600 --> 00:08:40,240
The Proof of Work also solves the problem of determining representation in majority

113
00:08:40,240 --> 00:08:41,920
decision making.

114
00:08:41,920 --> 00:08:47,880
If the majority were based on one IP address one vote, it could be subverted by anyone

115
00:08:47,880 --> 00:08:50,560
able to allocate many IPs.

116
00:08:50,560 --> 00:08:55,080
Proof of Work is essentially one CPU one vote.

117
00:08:55,080 --> 00:08:59,760
The majority decision is represented by the longest chain, which has the greatest Proof

118
00:08:59,760 --> 00:09:01,760
of Work effort invested in it.

119
00:09:01,760 --> 00:09:06,920
If a majority of CPU power is controlled by honest nodes, the honest chain will grow the

120
00:09:06,920 --> 00:09:11,000
fastest and outpace any competing chains.

121
00:09:11,000 --> 00:09:16,120
To modify a past block, an attacker would have to redo the Proof of Work of the block

122
00:09:16,120 --> 00:09:22,600
and all blocks after it, and then catch up with and surpass the work of the honest nodes.

123
00:09:22,600 --> 00:09:28,840
We will show later that the probability of a slower attacker catching up diminishes exponentially

124
00:09:28,840 --> 00:09:35,200
as subsequent blocks are added to compensate for increasing hardware speed and varying interest

125
00:09:35,200 --> 00:09:37,320
in running nodes over time.

126
00:09:37,320 --> 00:09:42,400
The Proof of Work difficulty is determined by a moving average targeting an average number

127
00:09:42,400 --> 00:09:44,080
of blocks per hour.

128
00:09:44,080 --> 00:09:48,680
If they're generated too fast, the difficulty increases.

129
00:09:48,680 --> 00:09:50,880
5.

130
00:09:50,880 --> 00:09:54,920
Network The steps to run the network are as follows.

131
00:09:54,920 --> 00:09:56,080
1.

132
00:09:56,080 --> 00:09:59,840
New transactions are broadcast to all nodes.

133
00:09:59,840 --> 00:10:01,320
2.

134
00:10:01,320 --> 00:10:04,920
Each node collects new transactions into a block.

135
00:10:04,920 --> 00:10:06,080
3.

136
00:10:06,080 --> 00:10:11,160
Each node works on finding a difficult Proof of Work for its block.

137
00:10:11,160 --> 00:10:12,680
4.

138
00:10:12,680 --> 00:10:18,280
When a node finds a Proof of Work, it broadcasts the block to all nodes.

139
00:10:18,280 --> 00:10:19,920
5.

140
00:10:19,920 --> 00:10:26,360
Nodes accept the block only if all transactions in it are valid and not already spent.

141
00:10:26,360 --> 00:10:28,080
6.

142
00:10:28,080 --> 00:10:32,120
Nodes express their acceptance of the block by working on creating the next block in the

143
00:10:32,120 --> 00:10:36,960
chain using the hash of the accepted block as the previous hash.

144
00:10:36,960 --> 00:10:41,440
Nodes always consider the longest chain to be the correct one and will keep working on

145
00:10:41,440 --> 00:10:43,040
extending it.

146
00:10:43,040 --> 00:10:48,080
If two nodes broadcast different versions of the next block simultaneously, some nodes

147
00:10:48,080 --> 00:10:51,000
may receive one or the other first.

148
00:10:51,000 --> 00:10:55,920
In that case, they work on the first one they received but save the other branch in case

149
00:10:55,920 --> 00:10:57,720
it becomes longer.

150
00:10:57,720 --> 00:11:04,040
The tie will be broken when the next Proof of Work is found and one branch becomes longer.

151
00:11:04,040 --> 00:11:08,520
The nodes that were working on the other branch will then switch to the longer one.

152
00:11:08,520 --> 00:11:13,640
New transaction broadcasts do not necessarily need to reach all nodes.

153
00:11:13,640 --> 00:11:18,600
As long as they reach many nodes, they will get into a block before long.

154
00:11:18,600 --> 00:11:22,360
Block broadcasts are also tolerant of dropped messages.

155
00:11:22,360 --> 00:11:26,960
If a node does not receive a block, it will request it when it receives the next block

156
00:11:26,960 --> 00:11:30,160
and realizes it missed one.

157
00:11:30,160 --> 00:11:31,920
6.

158
00:11:31,920 --> 00:11:35,880
Incentive By convention, the first transaction in a block

159
00:11:35,880 --> 00:11:41,440
is a special transaction that starts a new coin owned by the creator of the block.

160
00:11:41,440 --> 00:11:46,240
This adds an incentive for nodes to support the network and provides a way to initially

161
00:11:46,240 --> 00:11:51,920
distribute coins into circulation since there is no central authority to issue them.

162
00:11:51,920 --> 00:11:57,040
The steady addition of a constant amount of new coins is analogous to gold miners expending

163
00:11:57,040 --> 00:11:59,800
resources to add gold to circulation.

164
00:11:59,800 --> 00:12:05,360
In our case, it is CPU time and electricity that is expended.

165
00:12:05,360 --> 00:12:08,960
The incentive can also be funded with transaction fees.

166
00:12:08,960 --> 00:12:13,880
If the output value of a transaction is less than its input value, the difference is a

167
00:12:13,880 --> 00:12:19,800
transaction fee that is added to the incentive value of the block containing the transaction.

168
00:12:19,800 --> 00:12:24,720
Once a predetermined number of coins have entered circulation, the incentive can transition

169
00:12:24,720 --> 00:12:30,040
entirely to transaction fees and be completely inflation free.

170
00:12:30,040 --> 00:12:33,720
The incentive may help encourage nodes to stay honest.

171
00:12:33,720 --> 00:12:39,640
If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would

172
00:12:39,640 --> 00:12:45,160
have to choose between using it to defraud people by stealing back his payments or using

173
00:12:45,160 --> 00:12:47,360
it to generate new coins.

174
00:12:47,360 --> 00:12:53,160
He ought to find it more profitable to play by the rules, such rules that favor him with

175
00:12:53,160 --> 00:12:59,360
more new coins than everyone else combined, than to undermine the system and the validity

176
00:12:59,360 --> 00:13:01,920
of his own wealth.

177
00:13:01,920 --> 00:13:03,840
7.

178
00:13:03,840 --> 00:13:08,080
Reclaiming disk space Once the latest transaction in a coin is buried

179
00:13:08,080 --> 00:13:14,880
under enough blocks, the spent transactions before it can be discarded to save disk space.

180
00:13:14,880 --> 00:13:20,720
To facilitate this without breaking the block's hash, transactions are hashed in a merkle tree,

181
00:13:20,720 --> 00:13:24,320
with only the root included in the block's hash.

182
00:13:24,320 --> 00:13:28,960
Old blocks can then be compacted by stubbing off branches of the tree.

183
00:13:28,960 --> 00:13:32,120
The interior hashes do not need to be stored.

184
00:13:32,120 --> 00:13:36,680
A block header with no transactions would be about 80 bytes.

185
00:13:36,680 --> 00:13:44,520
If we suppose blocks are generated every 10 minutes, 80 bytes times 6 times 24 times 365

186
00:13:44,520 --> 00:13:47,520
equals 4.2 megabytes per year.

187
00:13:47,520 --> 00:13:53,080
With computer systems typically selling with 2 gigabytes of RAM as of 2008, and Moore's

188
00:13:53,080 --> 00:13:59,040
law predicting current growth of 1.2 gigabytes per year, storage should not be a problem,

189
00:13:59,040 --> 00:14:02,520
even if the block headers must be kept in memory.

190
00:14:02,520 --> 00:14:04,640
8.

191
00:14:04,640 --> 00:14:09,480
Record payment verification It is possible to verify payments without

192
00:14:09,480 --> 00:14:11,840
running a full network node.

193
00:14:11,840 --> 00:14:17,480
A user only needs to keep a copy of the block headers of the longest proof-of-work chain,

194
00:14:17,480 --> 00:14:22,880
which he can get by querying network nodes until he's convinced he has the longest chain,

195
00:14:22,880 --> 00:14:27,560
and obtain the merkle branch linking the transaction to the block it's time stamped in.

196
00:14:27,560 --> 00:14:32,800
He can't check the transaction for himself, but by linking it to a place in the chain,

197
00:14:32,800 --> 00:14:37,720
he can see that a network node has accepted it, and blocks added after it further confirm

198
00:14:37,720 --> 00:14:39,680
the network has accepted it.

199
00:14:39,680 --> 00:14:45,600
As such, the verification is reliable as long as honest nodes control the network, but it

200
00:14:45,600 --> 00:14:49,800
is more vulnerable if the network is overpowered by an attacker.

201
00:14:49,800 --> 00:14:54,360
While network nodes can verify transactions for themselves, the simplified method can

202
00:14:54,360 --> 00:14:59,880
be fooled by an attacker's fabricated transactions, for as long as the attacker can continue to

203
00:14:59,880 --> 00:15:01,760
overpower the network.

204
00:15:01,760 --> 00:15:06,760
One strategy to protect against this would be to accept alerts from network nodes when

205
00:15:06,760 --> 00:15:11,800
they detect an invalid block, prompting the user's software to download the full block

206
00:15:11,800 --> 00:15:15,680
and alerted transactions to confirm the inconsistency.

207
00:15:15,680 --> 00:15:20,120
Businesses that receive frequent payments will probably still want to run their own nodes

208
00:15:20,120 --> 00:15:24,400
for more independent security and quicker verification.

209
00:15:24,400 --> 00:15:26,200
9.

210
00:15:26,200 --> 00:15:30,720
Combining and splitting value Although it would be possible to handle coins

211
00:15:30,720 --> 00:15:36,640
individually, it would be unwieldy to make a separate transaction for every cent in a

212
00:15:36,640 --> 00:15:37,640
transfer.

213
00:15:37,640 --> 00:15:44,040
To allow value to be split and combined, transactions contain multiple inputs and outputs.

214
00:15:44,040 --> 00:15:49,120
Normally there will be either a single input from a larger previous transaction, or multiple

215
00:15:49,120 --> 00:15:55,720
inputs combining smaller amounts, and at most two outputs, one for the payment, and one

216
00:15:55,720 --> 00:15:59,280
returning the change, if any, back to the sender.

217
00:15:59,280 --> 00:16:04,720
It should be noted that fan out, where a transaction depends on several transactions, and those

218
00:16:04,720 --> 00:16:09,080
transactions depend on many more, is not a problem here.

219
00:16:09,080 --> 00:16:14,680
There is never the need to extract a complete standalone copy of a transaction's history.

220
00:16:14,680 --> 00:16:16,520
10.

221
00:16:16,520 --> 00:16:19,720
Privacy The traditional banking model achieves a level

222
00:16:19,720 --> 00:16:25,440
of privacy by limiting access to information to the parties involved and the trusted third

223
00:16:25,440 --> 00:16:26,520
party.

224
00:16:26,520 --> 00:16:32,040
The necessity to announce all transactions publicly precludes this method, but privacy

225
00:16:32,040 --> 00:16:37,400
can still be maintained by breaking the flow of information in another place, by keeping

226
00:16:37,400 --> 00:16:39,760
public keys anonymous.

227
00:16:39,760 --> 00:16:44,920
The public can see that someone is sending an amount to someone else, but without information

228
00:16:44,920 --> 00:16:49,120
linking the transaction to anyone, this is similar to the level of information released

229
00:16:49,120 --> 00:16:56,200
by stock exchanges, where the time and size of individual trades, the tape, is made public,

230
00:16:56,200 --> 00:16:58,600
but without telling who the parties were.

231
00:16:58,600 --> 00:17:03,880
As an additional firewall, a new key pair should be used for each transaction to keep

232
00:17:03,880 --> 00:17:06,920
them from being linked to a common owner.

233
00:17:06,920 --> 00:17:12,120
Some linking is still unavoidable with multi-input transactions, which necessarily reveal that

234
00:17:12,120 --> 00:17:14,920
their inputs were owned by the same owner.

235
00:17:14,920 --> 00:17:20,280
The risk is that if the owner of a key is revealed, linking could reveal other transactions

236
00:17:20,280 --> 00:17:23,080
that belonged to the same owner.

237
00:17:23,080 --> 00:17:24,600
11.

238
00:17:24,600 --> 00:17:28,440
Calculations We consider the scenario of an attacker trying

239
00:17:28,440 --> 00:17:33,760
to generate an alternate chain faster than the honest chain, even if this is accomplished.

240
00:17:33,760 --> 00:17:38,480
It does not throw the system open to arbitrary changes, such as creating value out of thin

241
00:17:38,480 --> 00:17:42,360
air or taking money that never belonged to the attacker.

242
00:17:42,360 --> 00:17:48,040
Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept

243
00:17:48,040 --> 00:17:49,680
a block containing them.

244
00:17:49,680 --> 00:17:56,280
An attacker can only try to change one of his own transactions to take back money he already

245
00:17:56,280 --> 00:17:57,280
spent.

246
00:17:57,280 --> 00:18:03,680
The race between the honest chain and an attacker chain can be characterized as a binomial random

247
00:18:03,680 --> 00:18:04,680
walk.

248
00:18:04,680 --> 00:18:09,760
The success event is the honest chain being extended by one block, increasing its lead

249
00:18:09,760 --> 00:18:11,520
by plus one.

250
00:18:11,520 --> 00:18:16,440
And the failure event is the attacker's chain being extended by one block, reducing the

251
00:18:16,440 --> 00:18:18,400
gap by minus one.

252
00:18:18,400 --> 00:18:23,200
The probability of an attacker catching up from a given deficit is analogous to the gambler's

253
00:18:23,200 --> 00:18:25,280
ruin problem.

254
00:18:25,280 --> 00:18:30,960
Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite

255
00:18:30,960 --> 00:18:34,760
number of trials to try to reach break even.

256
00:18:34,760 --> 00:18:39,600
We can calculate the probability he ever reaches break even, or that an attacker ever

257
00:18:39,600 --> 00:18:43,040
catches up with the honest chain as follows.

258
00:18:43,040 --> 00:18:47,360
P equals probability an honest node finds the next block.

259
00:18:47,360 --> 00:18:51,480
Q equals probability the attacker finds the next block.

260
00:18:51,480 --> 00:18:56,800
Qz equals probability the attacker will ever catch up from z blocks behind.

261
00:18:56,800 --> 00:19:01,840
Qz equals 1 if P is less than or equal to Q.

262
00:19:01,840 --> 00:19:06,040
Q over P to the z power if P is greater than Q.

263
00:19:06,040 --> 00:19:11,520
Given our assumption that P is greater than Q, the probability drops exponentially as the

264
00:19:11,520 --> 00:19:15,360
number of blocks the attacker has to catch up with increases.

265
00:19:15,360 --> 00:19:20,440
With the odds against him, if he doesn't make a lucky lunge forward early on, his chances

266
00:19:20,440 --> 00:19:24,600
become vanishingly small as he falls further behind.

267
00:19:24,600 --> 00:19:29,080
We now consider how long the recipient of a new transaction needs to wait.

268
00:19:29,080 --> 00:19:33,080
Before being sufficiently certain, the sender can't change the transaction.

269
00:19:33,080 --> 00:19:37,320
We assume the sender is an attacker who wants to make the recipient believe he paid him

270
00:19:37,320 --> 00:19:42,840
for a while, then switch it to pay back to himself after some time has passed.

271
00:19:42,840 --> 00:19:48,120
The receiver will be alerted when that happens, but the sender hopes it will be too late.

272
00:19:48,120 --> 00:19:52,760
The receiver generates a new key pair and gives the public key to the sender shortly

273
00:19:52,760 --> 00:19:54,400
before signing.

274
00:19:54,400 --> 00:19:58,720
This prevents the sender from preparing a chain of blocks ahead of time by working on

275
00:19:58,720 --> 00:20:03,960
it continuously until he is lucky enough to get far enough ahead, then executing the transaction

276
00:20:03,960 --> 00:20:05,480
at that moment.

277
00:20:05,480 --> 00:20:10,560
Once the transaction is sent, the dishonest sender starts working in secret on a parallel

278
00:20:10,560 --> 00:20:14,000
chain containing an alternate version of his transaction.

279
00:20:14,000 --> 00:20:19,080
The recipient waits until the transaction has been added to a block, and Z blocks have

280
00:20:19,080 --> 00:20:20,760
been linked after it.

281
00:20:20,760 --> 00:20:25,640
He doesn't know the exact amount of progress the attacker has made, but assuming the honest

282
00:20:25,640 --> 00:20:30,920
blocks took the average expected time per block, the attacker's potential progress will

283
00:20:30,920 --> 00:20:37,880
be a Poisson distribution with expected value lambda equals Z times Q over P.

284
00:20:37,880 --> 00:20:42,480
To get the probability the attacker could still catch up now, we multiply the Poisson

285
00:20:42,480 --> 00:20:47,000
density for each amount of progress he could have made by the probability he could catch

286
00:20:47,000 --> 00:20:48,600
up from that point.

287
00:20:48,600 --> 00:20:55,200
Sum from K equals 0 to infinity of lambda to the K power times e to the negative lambda

288
00:20:55,200 --> 00:21:04,760
over K factorial times Q over P to the Z minus K power if K is less than or equal to Z, or

289
00:21:04,760 --> 00:21:07,560
1 if K is greater than Z.

290
00:21:07,560 --> 00:21:13,640
Rearranging to avoid summing the infinite tail of distribution, 1 minus sum from K equals

291
00:21:13,640 --> 00:21:21,560
0 to Z of lambda to the K power times e to the negative lambda over K factorial times

292
00:21:21,560 --> 00:21:26,800
1 minus Q over P to the Z minus K power.

293
00:21:26,800 --> 00:21:32,800
Converting to C code, here Satoshi converts to C code as he explains, you can look at

294
00:21:32,800 --> 00:21:35,800
the code for yourself if you want in the show notes.

295
00:21:35,800 --> 00:21:41,000
Taking some results, we can see the probability drop off exponentially with Z.

296
00:21:41,000 --> 00:21:48,840
For here he shows that for Q equals 0.1, starting out with Z equals 0, P equals 1, but by the

297
00:21:48,840 --> 00:21:57,240
time you get to Z equals 10, P equals 0.0000012.

298
00:21:57,240 --> 00:22:05,640
And for Q equals 0.3, starting with Z equals 0 and P equals 1, by the time Z gets to 50,

299
00:22:05,640 --> 00:22:08,240
we have P equals 0.

300
00:22:08,240 --> 00:22:20,080
Solving for P less than 0.1%, here he shows that for P less than 0.001, Q equals 0.10

301
00:22:20,080 --> 00:22:22,440
for Z equals 5.

302
00:22:22,440 --> 00:22:30,040
12. Conclusion. We have proposed a system for electronic transactions without relying

303
00:22:30,040 --> 00:22:31,920
on trust.

304
00:22:31,920 --> 00:22:37,200
We started with the usual framework of coins made from digital signatures, which provides

305
00:22:37,200 --> 00:22:43,280
strong control of ownership, but is incomplete without a way to prevent double spending.

306
00:22:43,280 --> 00:22:49,960
To solve this, we proposed a peer-to-peer network using proof of work to record a public history

307
00:22:49,960 --> 00:22:56,840
of transactions that quickly becomes computationally impractical for an attacker to change if honest

308
00:22:56,840 --> 00:23:00,200
nodes control a majority of CPU power.

309
00:23:00,200 --> 00:23:07,240
The network is robust in its unstructured simplicity. Nodes work all at once with little

310
00:23:07,240 --> 00:23:13,200
coordination. They do not need to be identified, since messages are not routed to any particular

311
00:23:13,200 --> 00:23:18,080
place and only need to be delivered on a best effort basis.

312
00:23:18,080 --> 00:23:23,080
Nodes can leave and rejoin the network at will, accepting the proof of work chain as

313
00:23:23,080 --> 00:23:28,640
proof of what happened while they were gone. They vote with their CPU power, expressing

314
00:23:28,640 --> 00:23:35,200
their acceptance of valid blocks by working on extending them and rejecting invalid blocks

315
00:23:35,200 --> 00:23:37,560
by refusing to work on them.

316
00:23:37,560 --> 00:23:50,320
Any needed rules and incentives can be enforced with this consensus mechanism.

317
00:23:50,320 --> 00:23:56,280
And that's a wrap on this Bitcoin Out Loud episode of The Bitcoin Podcast. If you're

318
00:23:56,280 --> 00:24:01,640
a Bitcoin-only company interested in sponsoring another fucking Bitcoin podcast, head to

319
00:24:01,640 --> 00:24:07,640
bitcoinpodcast.net. You can also reach out to me on social media. On NoSter, go to primal.net

320
00:24:07,640 --> 00:24:13,760
slash walker. And if you want to follow the Bitcoin podcast on Twitter, go to at titcoinpodcast

321
00:24:13,760 --> 00:24:19,800
and at walkeramerica. You can always watch the video versions of this podcast at youtube.com

322
00:24:19,800 --> 00:24:25,280
slash at walkeramerica and at walkeramerica on rumble and ex.

323
00:24:25,280 --> 00:24:32,160
Bitcoin is scarce. There will only ever be 21 million. But Bitcoin podcasts are abundant.

324
00:24:32,160 --> 00:24:38,600
So thank you for spending your scarce time to listen to another fucking Bitcoin podcast.

325
00:24:38,600 --> 00:24:55,640
Until next time, stay free.