4 ms·

Explanation: bankA -> bankB -> bankC. bankC creates a secret number, hashes it and sends it to bankA. bankA sends money to bankB locked to hash. bankB can't ge

Explanation: bankA -> bankB -> bankC. bankC creates a secret number, hashes it and sends it to bankA. bankA sends money to bankB locked to hash. bankB can't get money until they have that secret number. bankB sends money to bankC locked to hash. bankC reveals secret number to bankB to unlock that money. bankB does the same with bankA. Tada, we eliminated the risk of bankB running away with money. This is the lightning network

csumtin 3y ago
I realise that this might seem a bit niche but we can use this to create a payment network(like visa). This system is better as the nodes in the network don't need to trust each other. Cast your mind back to 2008 and hopefully this means that one bank falling over doesn't bring down the whole system.
JumpCrisscross 3y ago
> we eliminated the risk of bankB running away with money This isn't a real risk with correspondent banks. Instead, it's counterparty risk: bankB failing while it holds the funds in transfer. That risk can be mitigated with smart contracts, but it's not eliminated. (Correspondent banks also take a portion of the client bank's fraud and AML risk.)
- csumtin 3y ago
  I think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back.
  - JumpCrisscross 3y ago
    > think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back Bank failing in this context would be the bridge (EDIT: contract) gets hacked. Hence mitigated, but not eliminated.
    - csumtin 3y ago
      If bankB is hacked, bankA still gets their money back or the payment is sent to bankC. So I still think the counterparty risk is eliminated between bankA and bankB
      - JumpCrisscross 3y ago
        > counterparty risk is eliminated between bankA and bankB Correct, but in its place is a new systemic risk with a real-world nonzero probability: the contract itself getting hacked. There isn't analogy for this in modern banking since the equivalent issue would either (a) get rolled back or (b) fold into the bank failing envelope. (There is analogy in pre-modern banking, though it largely revolved around debasement and invasion.)
        csumtin 3y ago
        True although I'm not talking about Ethereum smart contracts, I'm talking about Bitcoin ones which are very limited and not Turing complete. The lightning smart contract is like 20 lines and has been live since 2018, I feel the probability of the contract getting hacked is very low(famous last words!) https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs https://github.com/lightning/bolts/blob/master/03-transactio...
trompetenaccoun 3y ago
Fair but LN is not a smart contract. Bitcoin can't do smart contracts the way a chain like Ethereum does, it's functionality is very limited.
- csumtin 3y ago
  I'd argue it is a smart contract :) just not a Turing complete one

csumtin 3y ago

I realise that this might seem a bit niche but we can use this to create a payment network(like visa). This system is better as the nodes in the network don't need to trust each other. Cast your mind back to 2008 and hopefully this means that one bank falling over doesn't bring down the whole system.

JumpCrisscross 3y ago

> we eliminated the risk of bankB running away with money This isn't a real risk with correspondent banks. Instead, it's counterparty risk: bankB failing while it holds the funds in transfer. That risk can be mitigated with smart contracts, but it's not eliminated. (Correspondent banks also take a portion of the client bank's fraud and AML risk.)

csumtin 3y ago
I think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back.
- JumpCrisscross 3y ago
  > think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back Bank failing in this context would be the bridge (EDIT: contract) gets hacked. Hence mitigated, but not eliminated.
  - csumtin 3y ago
    If bankB is hacked, bankA still gets their money back or the payment is sent to bankC. So I still think the counterparty risk is eliminated between bankA and bankB
    - JumpCrisscross 3y ago
      > counterparty risk is eliminated between bankA and bankB Correct, but in its place is a new systemic risk with a real-world nonzero probability: the contract itself getting hacked. There isn't analogy for this in modern banking since the equivalent issue would either (a) get rolled back or (b) fold into the bank failing envelope. (There is analogy in pre-modern banking, though it largely revolved around debasement and invasion.)
      - csumtin 3y ago
        True although I'm not talking about Ethereum smart contracts, I'm talking about Bitcoin ones which are very limited and not Turing complete. The lightning smart contract is like 20 lines and has been live since 2018, I feel the probability of the contract getting hacked is very low(famous last words!) https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs https://github.com/lightning/bolts/blob/master/03-transactio...

trompetenaccoun 3y ago

Fair but LN is not a smart contract. Bitcoin can't do smart contracts the way a chain like Ethereum does, it's functionality is very limited.

csumtin 3y ago
I'd argue it is a smart contract :) just not a Turing complete one