The document discusses future advancements in Bitcoin technology, focusing on concepts such as Schnorr signatures, MAST (Merkelized Abstract Syntax Tree), and Taproot. These innovations aim to improve transaction efficiency, enhance privacy, and reduce transaction sizes by allowing for aggregation and batch verification of signatures. Additionally, the introduction of new opcodes and interactive scripts is explored, highlighting their potential impact on Bitcoin's scripting capabilities.

1. What’s next for Bitcoin?

2. Topics
● Schnorr
● MAST
● Taproot
● Graftroot

3. Elliptic curves refresher (or intro, as the case might be)
● It all starts with a prime number, e.g.
p=2256
- 232
- 29
- 28
- 27
- 26
- 24
- 1
● And a regular looking equation, such as
y2
= x3
+ 7
● And a point G (x,y - calculated from
x=79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
● ECDSA sig (r,s) => s = r-1
(H(m)+ka)

4. Operations
● P=kG
● One can add points on the curve P+R=Q
● One can multiply points with scalars
R=xP (can be seen as R=P+P+....+P - x
times)
● Most important: aG+bG=(a+b)G
(translates to: sum of pubkeys has priv
key the sum of privkeys)

5. ECDSA
Img Src https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744

6. Schnorr signature
Img Src https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744

7. Warning!
● The previous graphs are valid for real
numbers and we’re actually working in Zp
which results in a graph that looks
more like a scatterplot

8. Real numbers vs prime field
Img Src https://www.maximintegrated.com/en/app-notes/index.mvp/id/5767

9. Schnorr
● Signature (k priv key P=kG, m message
to sign, r - random, R=rG)
s = r - h(m||R)k then signature for m
is (r,s)
● Verification
sG = rG - h(m||R)k => S = R - h(m||R)P

10. Aggregation
● The immediate benefit of Schnorr sig is
that they can be aggregated and batch
verified => reduction in tx size +
faster transaction (maybe even block)
validation time
● BIP-SCHNORR (no official # yet)

11. Other advantages
● Provable secure in ECDLP random-oracle
model (ECDSA is _not proven_)
● Non-Maleable (in ECDSA 3rd party can
alter sig for P and m into another sig
for P and m)
● O(1) - due to aggregation
● Batch verification

12. Scripts
● Any script can be represented as a tree
○ To be more specific: even as a binary tree
○ We’re talking about stack-based Bitcoin-like scripts
○ Polish notation anyone?
● This means that one can make a
commitment to a script by Merkle-izing
it

13. Example
Image src https://en.cryptonomist.ch/2019/05/19/mast-bitcoin-privacy-scripts/

14. MAST-ized
Image src https://en.cryptonomist.ch/2019/05/19/mast-bitcoin-privacy-scripts/

15. MAST
● Scripts can be anyway revealed only on
spend (BIP 16)
● Benefit: one does not have to reveal
anything than the executed path
● Saves space
● More Privacy!
● BIP 114,117

16. Bitcoin Scripts - P2PKH
● “Standard signature”:
OP_DUP OP_HASH160 <pkh>
OP_EQUALVERIFY OP_CHECKSIG
● Same thing in “SegWit lingo”
OP_0 <pkh>

17. Bitcoin Scripts - P2SH
● P2SH
OP_HASH160 <scripthash> OP_EQUAL
● In SegWit lingo (P2WSH)
OP_0 <scripthash>
● The data length classifies vs previous
case (20 bytes here vs 32 before)

18. Taproot
● P2SH and P2PKH are distinguishable
● Can we merge both?
○ E.g. ContractHash = P + h(z||P)G
● Once we do this
○ Spending means just signing with k+h(z||P) <- works even now
OR
○ Provide script z and let the stack decide <- needs a new opcode

19. Putting it together
● New opcode (OP_NEW)
● In output OP_NEW <pubkey>
● In input (to spend)
○ Provide <signature> in P2PKH mode
○ OR
○ <P> <script>[]<arguments> (taproot)
○ <scriptsig> <script> []<arguments> (graftroot)
● BIP-TAPROOT (no official # yet)

20. Graftroot
● Extension of Taproot
● Focuses on the “everybody agrees” case
● Allows delegating signing to a separate
script
● Is interactive (compared to Taproot
which is not)

21. ELTOO
● SIGHASH_NOINPUT (BIP 118)
● HF only for SegWit scripts with ver>=1
● Allows an input _not_ to reference a
specific previous output (commitment to
pubkey, not to input)
● Tx can be bound to any output that
matches <witness> and for which
<witnessProg> yields true