3 ms·

JPMorgan

treis 8y ago
Which is the problem that JPM Coin is aiming to solve. For them to use a DB solution requires both parties to the transaction to be customers of JP Morgan. A block chain issued coin doesn't require that and, therefore, has some theoretical advantage. Of course it remains to be seen how true that turns out to be. There is a DB based solution for financial transfers today in SWIFT. It has numerous flaws that a block chain based solution legitimately solves.
- hcknwscommenter 8y ago
  I am not saying SWIFT is perfect, but please enumerate these flaws and the ways in which blockchain legitimately solves these flaws without introducing an equal number of equally problematic flaws.
  - treis 8y ago
    SWIFT transactions can be slow depending on the banks involved. If a bank's SWIFT credentials are compromised the attackers can transfer all the funds a bank controls. With a blockchain coin it would require the private key of the customer to send the coins.
    - root_axis 8y ago
      > With a blockchain coin it would require the private key of the customer to send the coins. There are no "customers", this is a private blockchain where only banks participate.
      - treis 8y ago
        Obviously the customers are the businesses with money deposited at the bank.
        root_axis 8y ago
        > If a bank's SWIFT credentials are compromised the attackers can transfer all the funds a bank controls. With a blockchain coin it would require the private key of the customer to send the coins. Replace "SWIFT credentials" with "private key" and you have exactly the same scenario.
        treis 8y ago
        You know if you're going to be wrong you should be less vociferous about it. Compromising SWIFT credentials allows you to send money from any account. Compromising a customer's private key would only allow you to send money that's in that one account.
        root_axis 8y ago
        > You know if you're going to be wrong you should be less vociferous about it Needless petty snark. > Compromising SWIFT credentials allows you to send money from any account. Compromising a customer's private key would only allow you to send money that's in that one account. If the "customers" are "banks" as you stated, then there is a 1:1 relationship between SWIFT credentials and private keys which allow one to sign transactions on behalf of the "customer" (bank).
        treis 8y ago
        >If the "customers" are "banks" as you stated, I clearly didn't say that: >Obviously the customers are the businesses with money deposited at the bank. >Needless petty snark. It's unfortunate you took it as snark and not advice
        root_axis 8y ago
        > the customers are the businesses with money deposited at the bank. Once again, this is a blockchain controlled by BANKS. Customer's of the bank do not participate in this. What are you not understanding? > It's unfortunate you took it as snark and not advice More needless petty snark. I'm done with this conversation.
    - creeble 8y ago
      How is compromising SWIFT credentials different than compromising a private key?
- root_axis 8y ago
  > It has numerous flaws that a block chain based solution legitimately solves. This is false. It solves nothing. If you disagree please detail a specific example instead of vaguely claiming it solves lots of problems. > For them to use a DB solution requires both parties to the transaction to be customers of JP Morgan JP controls the network, so they must already have a prearranged agreement with JP in order for any of this to be possible anyway, at that point, the blockchain doesn't give you anything that couldn't be done faster and cheaper with public/private keys and digital signatures.
  - stale2002 8y ago
    Sure, I'll give a problem. A private database is not public to the customers. Customers have to trust that the database isn't being changed behind the scenes. A Blockchain makes it transparent to all parties in the network, so you don't have to trust that nothing wierd is going on where you wont be able to see it.
    - root_axis 8y ago
      > A private database is not public to the customers. Customers The article describes a private blockchain which is not public to customers, so your example does not work here. I'm willing to consider any other specific examples you can think of.
      - cachvico 8y ago
        The customers here in question are other large institutions (for now).
      - stale2002 8y ago
        It is public to the other participants in the network. "Customers" in this instance is in reference to the banks and businesses that would be apart of this Blockchain. The "private" Blockchain is not private to the participants. IE, other banks. This is bank to bank technology that is meant to replace the current settlement layer that banks currently use, but is quite slow. IE, wire transfers between banks, that can be made much faster, and require less trust the current methods that banks transfer money between each other. Right now settlement times between banks are high, or require that they trust some centralized, non transparent database. This, on the other hand, reduces the trust necessary between banks.

JPMorgan

Which is the problem that JPM Coin is aiming to solve. For them to use a DB solution requires both parties to the transaction to be customers of JP Morgan. A block chain issued coin doesn't require that and, therefore, has some theoretical advantage. Of course it remains to be seen how true that turns out to be. There is a DB based solution for financial transfers today in SWIFT. It has numerous flaws that a block chain based solution legitimately solves.

hcknwscommenter 8y ago
I am not saying SWIFT is perfect, but please enumerate these flaws and the ways in which blockchain legitimately solves these flaws without introducing an equal number of equally problematic flaws.
- treis 8y ago
  SWIFT transactions can be slow depending on the banks involved. If a bank's SWIFT credentials are compromised the attackers can transfer all the funds a bank controls. With a blockchain coin it would require the private key of the customer to send the coins.
  - root_axis 8y ago
    > With a blockchain coin it would require the private key of the customer to send the coins. There are no "customers", this is a private blockchain where only banks participate.
    - treis 8y ago
      Obviously the customers are the businesses with money deposited at the bank.
      - root_axis 8y ago
        > If a bank's SWIFT credentials are compromised the attackers can transfer all the funds a bank controls. With a blockchain coin it would require the private key of the customer to send the coins. Replace "SWIFT credentials" with "private key" and you have exactly the same scenario.
        treis 8y ago
        You know if you're going to be wrong you should be less vociferous about it. Compromising SWIFT credentials allows you to send money from any account. Compromising a customer's private key would only allow you to send money that's in that one account.
        root_axis 8y ago
        > You know if you're going to be wrong you should be less vociferous about it Needless petty snark. > Compromising SWIFT credentials allows you to send money from any account. Compromising a customer's private key would only allow you to send money that's in that one account. If the "customers" are "banks" as you stated, then there is a 1:1 relationship between SWIFT credentials and private keys which allow one to sign transactions on behalf of the "customer" (bank).
        treis 8y ago
        >If the "customers" are "banks" as you stated, I clearly didn't say that: >Obviously the customers are the businesses with money deposited at the bank. >Needless petty snark. It's unfortunate you took it as snark and not advice
        root_axis 8y ago
        > the customers are the businesses with money deposited at the bank. Once again, this is a blockchain controlled by BANKS. Customer's of the bank do not participate in this. What are you not understanding? > It's unfortunate you took it as snark and not advice More needless petty snark. I'm done with this conversation.
  - creeble 8y ago
    How is compromising SWIFT credentials different than compromising a private key?
root_axis 8y ago
> It has numerous flaws that a block chain based solution legitimately solves. This is false. It solves nothing. If you disagree please detail a specific example instead of vaguely claiming it solves lots of problems. > For them to use a DB solution requires both parties to the transaction to be customers of JP Morgan JP controls the network, so they must already have a prearranged agreement with JP in order for any of this to be possible anyway, at that point, the blockchain doesn't give you anything that couldn't be done faster and cheaper with public/private keys and digital signatures.
- stale2002 8y ago
  Sure, I'll give a problem. A private database is not public to the customers. Customers have to trust that the database isn't being changed behind the scenes. A Blockchain makes it transparent to all parties in the network, so you don't have to trust that nothing wierd is going on where you wont be able to see it.
  - root_axis 8y ago
    > A private database is not public to the customers. Customers The article describes a private blockchain which is not public to customers, so your example does not work here. I'm willing to consider any other specific examples you can think of.
    - cachvico 8y ago
      The customers here in question are other large institutions (for now).
    - stale2002 8y ago
      It is public to the other participants in the network. "Customers" in this instance is in reference to the banks and businesses that would be apart of this Blockchain. The "private" Blockchain is not private to the participants. IE, other banks. This is bank to bank technology that is meant to replace the current settlement layer that banks currently use, but is quite slow. IE, wire transfers between banks, that can be made much faster, and require less trust the current methods that banks transfer money between each other. Right now settlement times between banks are high, or require that they trust some centralized, non transparent database. This, on the other hand, reduces the trust necessary between banks.