3 ms·
This raises a very interesting point. Much of the problems with blockchain's, i.e. proof-of-work, on-chain transactions needing everyone to know about them, are
by er4hn 5y ago
This raises a very interesting point. Much of the problems with blockchain's, i.e. proof-of-work, on-chain transactions needing everyone to know about them, are because there are no central authorities baked into the design that can behave in opaque ways.
Yet, centralized services still spring up to handle transactions: OpenSea for NFTs, Coinbase for cryptocoin transactions. These services in turn still rely on a sea of middlemen which take a cut, or "gas" fees for their work. If you are transfering coins among several services then there are fees for each transfer, etc.
So tying this back to present day, mainstream, finance: When you run a credit card there are several middlemen between the cardholder and the merchant. This diagram (https://merchantcostconsulting.com/lower-credit-card-processing-fees/understanding-credit-card-networks/ https://merchantcostconsulting.com/lower-credit-card-process...) suggests 4 intermediaries, each taking a cut.
In theory each of these provides a service - but how many are required in modern times? Let's say that the cardholder just wants to pay the merchant, and the merchant wants to maximize their take. In cryptocoin-land you would have a direct transaction with the merchant. This works because you cannot double pay. In trad-finance land you need to have your issuing bank state that you have the funds. Credit cards provide a level of abstraction where the merchant gets paid now and the credit card provider collects later. This all happens live.
What if instead you had a system where:
- Card holder uses a computing device (say a smartphone with TPM) and that cryptographically signs transactions to say that the card holder requested this.
- Issuing bank gives the card holder a signed certificate each week saying: This is account holder #XXXXX. They can purchase up to $YYY at one time.
- Card holder provides the cert to merchant upon wanting to make a purchase along with a signed receipt indicating a transfer of money. You could add a pin to be entered on each transaction as 2FA.
- Merchant gets this crypto-receipt and has some reasonable amount of time to turn it in to the issuing bank (say 1 month) and collect payment.
- Issuing bank gives merchant money for receipt and charges account holder. Account holder does normal procedures of paying for things, complaining about charges, etc.
This scheme has a few advantages and feels very similar to how I sort of understand credit cards work in Europe.
- Issuing bank can get a larger take since there are less intermediaries.
- Merchant can get a larger take since there can be less fees.
- There is a reasonable assurance of lack of fraud due to 2FA, and TPM storing signing key.
- This does not require live internet access nor live responses.
Why is there nothing like this? What are the drawbacks? Tying back to the parent discussion, is this a reasonable optimization on top of crypocurrency as it exists today?
- drdeca 5y agoWhat stops someone from sending (large number) of transactions which each spend less than $YYY at any one time, but total much more than their balance? If you have an actual person named and you have their street address and whatnot, you (rather, the bank) can hold them accountable for the missing money using like, laws and courts, but, if this is all pseudonymous internet money, there doesn’t seem to be much recourse? So, in that case, the case where you have no recourse if they don’t actually have all that they’ve paid, it is important to be able to verify their current account balance including all transactions they’ve made so far, not just ones that have already been fully processed (or at least, be able to provide the good or service in a way that only takes effect insofar as they end up actually having enough money to pay). If you could somehow limit the number of transactions they are capable of making in the given amount of time, what you said could work, but I don’t see how to achieve that? I guess maybe if the computational cost of making a transaction was large enough, you could make the limit on the size of individual transactions small enough that they couldn’t produce enough to use their whole balance within the allotted time period, because they don’t have enough computational resources? But then how do you know how much computational resources they have? Seems like this could result in mining farms being able to spend more than they have. Though, if this attack was only possible with a large hardware investment, one could still detect the attack afterwards, and just, delete the money spent this way? Oh, or, if one can’t spend money that one got since the previous periodic amount of time, needing to wait until the next signed message from the bank, then, there would be no transactions that are only seemingly valid because of the invalid ones, and so, then you just have people not getting the money they were expecting, But if the only way this can happen is if someone makes a really big number of transactions, then probably many of the recipients were in on the scheme, and so them not getting the money is maybe fine?? Hm. But not clear how you could determine which ones were in on the scheme and which ones would be unfairly harmed by not getting the money they were promised. Though, if you are going to have a bank centralizing things, why not just, send the transactions through the bank? Are they any more of a middleman when they process the transactions as part of the paying the money instead of later?