FinTech - Lecture 12 : Other Ledger Technology and Applications (2)
These slides were used in the lecture 12 of FinTech - Financial Innovation and the Internet 2020 Fall at the Graduate School of Business and Finance, Waseda University, on December 18, 2020.
Lecture 12 : Other Ledger Technology and Applications (2) Kenji Saito Professor, Graduate School of Business and Finance, Waseda University Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.1/25
required You do need to speak often (we are going to have a lot of dialogue) We will use breakout rooms a lot, but those won’t be recorded unless you do it yourselves (need to be allowed) Keep your Zoom client updated! We might use latest features The recordings could be used for research on online learning Transcribed for use and anonymized Will let you know when the necessity arises Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.2/25
and chat text will be posted at Moodle and Discord Trial automatic transcription of the lecturer’s part will be posted at Discord Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.3/25
— how to disappear completely More on Anonymity UTXO and anonymity Mixing with or without trust More on Ethereum Applications and demonstrations Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.5/25
a public key digest In Ethereum, which manages account status (balance, etc.) rather than UTXO (coin with destination), it’s difficult to adopt the Bitcoin-like method of changing the receiver’s address from transaction to transaction Which is not a perfect way to hide themselves anyway zk-SNARKs, zero-knowledge proof algorithm used in Zcash, has also been implemented for Ethereum Can conceal transactions (Who sent it to whom ← not straightforward, and) how much? Deployed with Byzantium hardfork in 2017 Gas (transaction cost) is expensive Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.8/25
3 parts G is Generator : G(λ, C) → (pk, vk) where C is a circuit, λ is a secret Circuit (or function) C returns true or false; pk is the prover key, vk is the verifier key P is Prover : P(pk, x, w) → π where x is the public input of C, w (witness) is the secret input of C π is the proof V is Verifier : V (vk, x, π) = true ⇒ ∃w : C(x, w) = true Can perform in Ethereum by executing V inside smart contracts G and P (knows secret) are executed “off-chain” so to speak Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.9/25
hash function H The contract manages H(a’s balance) for all accounts a C s (x, w) for sender : x is [H(pre-tx balance), H(post-tx balance), H(remittance)], w is [pre-tx balance, remittance] Confirm pre-tx balance ≥ remittance Apply H to w to verify that H(pre-tx balance) and H(remittance) in x are correct Verifies that H(post-tx balance) in x equals H(pre-tx balance − remittance) C r (x, w) for receiver : x is [H(pre-tx balance), H(post-tx balance), H(remittance)], w is [pre-tx balance, remittance] Apply H to w to verify that H(pre-tx balance) and H(remittance) in x are correct Verifies that H(post-tx balance) in x equals H(pre-tx balance + remittance) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.10/25
arguments (sender address is self-evident as the caller of the contract) Receiver address, H(remittance), H(post-tx balance s ), H(post-tx balance r ) π s , π r obtained by applying P in advance Verifies sending by V (vk s , [H(balances ), H(post-tx balances ), H(remittance)], π s ) Verifies receiving by V (vk r , [H(balancer ), H(post-tx balancer ), H(remittance)], π r ) Replaces both H(balance) with their H(post-tx balance) Sender and receiver need to communicate off-chain They cannot tell how much each other had and has now Others cannot tell, in addition to the above, how much was sent But they can tell who sent money to whom Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.11/25
Bob is known To avoid preimage at- tacks, balances and re- mittances should contain many digits below deci- mal point Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.12/25
method of remittance using zk-SNARKs that conceals the following, and write the algorithm briefly (in English) Who sends money? ← NEW! To whom? ← NEW! How much? How much were the balances of those before remittance, and how much afterward? Is your solution perfect? What problems are there? Deadline and how to submit December 15, 2020 at 23:59 JST From Moodle (mandatory) Optionally, you can also post to #assignments channel at Discord So that your classmates can read your report, refer to it, and comment on it Just plain text, and be concise, please Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.14/25
Measures . . . how to improve the class 13 out of 16 students submitted (as of Wednesday; always better late than never) Your answers : Fixed third party, like mixing (5) / using digests of addresses (4) / using a ticket (1) / checking transaction history (1) / non zk-SNARKs solution (1) / ring signature (1) / not exactly an answer (1) Nice try! Some referred to techniques used in Zcash and/or Monero Ring signature would be an interesting topic to explore Please note : A cryptographic hash function is not an encryption (as we cannot decrypt the output) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.15/25
to receive amount “$” As Kenji mentioned on Discord, having the receiver initiate the contract is technically possible, so as long as Carol and Anna coordinate properly, this should be feasible 2. Using Kenji’s method (Lecture 11, pg. 10; henceforth K-Method) for hiding the amount sent and balances involved This is entirely necessary because even if Carol is a mediator, it might be easy for an outsider to see Anna pay amount “$” to Carol and Carol pay amount “$” to Bob, making the transaction apparent Also, if we assume Carol is some kind of service (highly likely) some nosey people might be paying attention 3. Carol initiates a transaction with Bob 4. Amount “$” is remitted via the K-method to hide values once again Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.16/25
reliability of the service, is that I imagine Carol would still need to know Bob and Anna’s public keys Since I have not used the service, I am still not certain whether the following is possible, but I think it could theoretically fix that issue: Register with Carol’s service with H(public_key) and use a transaction process similar to the K-method to hide the public key the same way it hides w ⇒ Pretty good! Although in Ethereum, H(public_key) is like the identifier (the address of an account), and you would need something like H(H(public_key)) Not quite strong against guessing the preimage (Like if you suspect that Anna paid Bob, and know their account addresses) Have to solve how to perform receiver-initiated transaction without revealing the sender’s identity So-called K-Method is well-known, and not mine Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.17/25
as the one on the lecture; Before the transaction, sender and receiver needs to communicate off-chain with receiver’s address In addition, sender needs to find a third party to invoke a contract and pay him in advance (with whatever off-chain) Sender also needs to give the third party hash_receiver_address After the above things are done, the third party starts to invoke a contract with (hash_receiver_address), and the rest things would be the same as the one on the lecture Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.18/25
revealed to public; Receiver’s address are not revealed as well; Remittance and balance would not revealed as it’s stated on lecture Problem: Sender’s information may be known by a third party; A third party needs to accept payment off-chain; It may require trust for a third party (if a third party is authorized, is it contradictious to the concept of decentralization?) ⇒ Pretty good! Perhaps the sender’s address is also hashed Need for a third party is not exactly contradicting to decentralization as long as their behaviors can be verified (instead of trusted) (cf. TumbleBit) Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.19/25
known solution) H′ can be any arbitrary function, but linkability remains a problem Balance’s digits below decimal point is like a private key, protected by H Carole can run verifiers prior to issuing a trans- action to verify if she can really receive the fee Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.20/25
for anonymity Build a circuit that runs through multiple nodes from the user to the terminating node The user shares a shared key with each node that appears on the circuit (the user does not tell who they are) Data encryption is applied for the terminating node, and then for each node appearing in the circuit in reverse order, and finally the data is sent The relay peels off the encryption at each hop, as if it were an onion, and sends it to the next node The relay has no way of knowing what content is being sent from whom to whom Reference Tor : https://www.torproject.org There are concerns about its application to crimes, but it is also a tool for protecting citizens’ privacy and enforcing human rights Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.21/25
by now Any questions so far? Any answers? Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.22/25
and FinTech i.e., please select one or more from “settlement and remittance”, “asset management”, “deposits and loans”, “financing”, “insurance”, and “capital market” Apply FinTech to it with respect to self-driving cars Deadline and how to submit January 5, 2021 at 17:59 JST From Moodle (mandatory) Optionally, you can also post to #assignments channel at Discord So that your classmates can read your report, refer to it, and comment on it Just plain text, and be concise, please Lecture 12 : Other Ledger Technology and Applications (2) — FinTech — Financial Innovation and the Internet 2020 Fall — 2020-12-18 – p.24/25
ks91
tadaken3
ymd65536
sudoakiy
tkhresk
mrbobbytables
ryosukeigarashi
niwatakeru
nikkei_engineer_recruiting
tdpauw
techiro
emiki
masaaki_k
paulrobertlloyd
garrettdimon
reverentgeek
chriscoyier
tammyeverts
addyosmani
marcelosomers
brettharned
cassininazir
lara
jnunemaker
