You could get close to a binary output with an option spread with a tight range of strikes (e.g. buying a call at price X, and selling a call at price X+1). If the stock price goes above the high strike it is a maximal payout one way, and below the low strike maximal payout the other way. If the strikes are close compared to movements of the stock and near the current price of the stock, the outcome is likely to be nearly binary. If the stock settles between the strikes the payout would be partial and continuous, but that window is very small.
Thats not necessarily true if its the weather service, post office or whatever. I am no Twitter fan/user, but its a decent format for circulating government announcements that people will actually see.
The argument is that its fair to label NPR as govt funded, because they technically are, but Twitter is not exactly in a hurry to apply this rule anywhere else.
What's sad is that people just automatically assume every government is altruistic when history has proven that to be unequivocally false. There is not ONE government in history that hasn't committed disgusting atrocities against its people.
When you realize that, it becomes clearly easy to see that you ought not put full trust media that is backed by government when every government has used media like this to push evil propaganda on to its citizens.
A normal pattern is to tier storage into a hot wallet and a cold wallet. Hot wallet is used for daily operations and can have lower security, but has a very low percentage of value, so that if hacked the exchange and eat the loss. The cold wallet can have very very high security measures such as multisig, physical security, geographic distribution, etc, and only needs to be periodically accessed.
Analogy in a old bank with cash or gold is hot wallet = cash that tellers have on hand, cold wallet = vault in the back that has everything else.
Yep. You can also put cold funds behind a multisig, which to use the vault in the back of the bank example, would require two managers to turn a key at the same time to open the vault.
It is fantastic that a company operating with such horrific practices is dead. While we are at it, when can we fix similar issues below with mainstream financial systems that millions of people are still using?
- Social security numbers are used as a secret for identification, despite being in plaintext and having so low entropy as to be guessable, and originally issued on a card literally saying "Not for Identification".
- Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.
- Credit card numbers are similarly a private number used as a public number, and printed on plaintext on the card.
Is there any effort working on bringing asymmetric encryption to these systems or to replace them that has a reasonable chance of working?
> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.
The same principle (i.e. knowing an account number means being able to debit it) works surprisingly well in many European countries for direct debits, and the account number is considered even less of a secret than it is in the US. For example, many freelances routinely print it on their invoices sent out to clients, have it as part of their e-mail signature, or even prominently feature it on their website.
What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit. An accountholder can literally click a button on their bank's app or website and they get the funds back immediately, no questions asked, within 8 weeks of the original debit date.
This, in turn, means that it is in the initiating party's self-interest to only accept this form of payment in high-trust situations, and not just like a low-fee replacement for credit and debit cards that shifts some amount of fraud risk to the accountholder or their bank.
> What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit.
It also helps that the accountholder has to allow each party that will debit money from their account. By default, those requests are denied.
"Positive pay" is available for checking accounts in the US, though I've never heard of it used outside of business accounts, and only then by request (and probably extra fees).
As a person you can only send them money. As a business you can initiate a direct debit which withdraws money. However you are attesting that they signed a direct debit agreement with you and provided their account number and agreed on the amount to pay.
This is the same as a credit card - you can charge any card with just the number and a couple of basic details, however if there's a complaint "I found these CC details on a random website" isn't accepted, you need to show the card holder agreed to the charge. If you don't provide the evidence the transaction is reversed.
That is usually not how credit cards work anymore. Sure, you can try to charge any card but if it is issued by a European bank it will very likely be denied and you will be asked to do a Strong Customer Authentication.
Same applies to SEPA direct debit. Here in Sweden most (all?) banks requires the customer to sign digitally before any direct debit mandate is created.
Yes, if you set up a direct debit agreement with a bank you can do that. If you'd actually try what you suggest it will be revoked quickly and charges filed as your identity is known.
> Do you mean that if I know a German bank account number I can just withdraw money for me?
You most likely can't, because if you have to ask this you don't have an agreement with a SEPA Direct Debit originating bank that lets you :)
And even if you decide to open one now: Given the risks involved for the originating bank, they will heavily scrutinize your business case and demand considerable collateral and/or payout time limits.
The thing that’s being missed here is that direct debits can be disputed in the same way a credit card payment can, and by default the customer wins. Their money will be refunded immediately by the bank, who will then go after you to get it back.
Yes and no. Swedish banks for example will just deny direct debits unless the customer has explicitly agreed to let their accounts be charged. So direct debit works differently per country and per bank.
This does have a minor drawback on the service provider side as allowing people to sign up for a service with direct debit is hard to get right, so many services prefer to offer credit card payment even if it is more expensive. There is no way for you to verify that a person signing up is actually the account holder save for doing the "we debited 1c on your account" thing, which takes a few days.
Yes, and that's arguably by design. If you need confirmation of funds, cardholder/accountholder authentication, and a dispute mechanism that doesn't side with the customer in 100% of scenarios, SEPA Direct Debit is probably not the payment method you want.
> the "we debited 1c on your account" thing
This doesn't actually work with SEPA Direct Debits, since there is no such thing as "disputing a reversal" or "compelling evidence": If the accountholder says "funds back, please", the involved banks have to oblige.
In fact, direct debits are so reversible/non-final that it's SOP for bankruptcy managers to claw back all of the last 8 weeks' worth of direct debits drawn on a bankrupt person's or entity's account, which can be quite surprising for debtors.
In other words, it's possibly a better mental model to think of direct debits as a request for a wire in 8 weeks that gets earmarked for approval by default if enough funds are present, but that accountholders can cancel at any point in time, as far as finality (but not liquidity) is concerned.
The main problem is that if the service provider has no proof that they legitimately had a contract signature, the account holder can reverse the transaction for much longer.
> What makes it work is that, under the SEPA Direct Debit framework, the risk of fraud and insufficient funds is 100% on the party initiating the direct debit.
Additionally, you need to have a direct debit agreement with your bank to be able to initiate a direct debit. You need to show at least some legitimate banking history (and a government-issued ID) to get one, and they come with limits on how many and how much you can debit per period, and your bank will terminate the agreement if your reversal rate is higher than normal.
How do you approve a payee with your bank? At the time you grant them permission to debit your account, or at the time of the first payment?
There is no technical channel for the former within the SEPA Direct Debit framework (i.e. the first time the payer's bank learns about a mandate is with the first direct debit), so I'm wondering if this is a different/domestic direct debit scheme.
Traditional banking is sufficiently slow enough that things can be reversed before permanently settled. The "slow" speed of moving money is a feature. It's designed for humans who make mistakes all the time.
I agree that it is a feature, but that feature didn't come with any downsides initially when the speed of everything else was also slow. The downsides are now substantial as the customer expects higher speeds. The downsides of not having the option to have final settlement quickly also seems to be a source of many other problems.
We also don't even need to change this aspect of traditional banking in order to add strong asymmetric encryption in front of the system. That would nip most fraud in the bud, and if nothing else save a lot of effort that goes into fraud schemes, prevention, and reversal.
Honestly, I don't really see this. Small personal transactions happen via Cash, Venmo, PayPal, Zelle, etc. without much issue or friction. As far as the general consumer is concerned it is instant.
Large business transactions generally (not always, obviously) do not have the sense of urgency that would require fast settlement. There's some market maker stuff that benefits from fast settlement, but that's not exactly a reason to push whole new system out to everyone.
The biggest "benefits" of crypto are not benefits to the average consumer going about their daily life. Instead of dealing with fraud you'd have to deal with customer service issues for actual customers who forgot/lost their keys. And, honestly, you'd probably have to deal with more fraud. Your phone gets hacked, your keys get stolen, and then what… all your money is irreversibly gone?
You are imagining a false dichotomy where things like fast and final settlement, or self custody are forced onto every user, and pointing out the obvious problems with that scenario. They are not good defaults, but they are great to have as options to protect customers against a fraudulent or over leveraged system. It is a bit like any protected right-- you don't have to directly make use of it for it to be valuable, the real value is in the optionality you have to be able to use it, and the risk that optionality poses to those who would exploit the absence of the right.
Not really. Fast (immutable) settlement is terrible for humans. Self custody is more or less incompatible with our modern world. And despite that, there are ways to do both without crypto—hand someone stacks of cash and keep gold in a safe under the floorboard. Both of these options exist.
You are repeating the same false dichotomy by stating again that final settlement and self custody are bad defaults for the entire world. That isn't want I'm saying, I am saying a choice is better than no choice at all. I'm also not saying anything about crypto. Gold and cash are also useful instruments that should be financial instruments for everyone also.
> The downsides are now substantial as the customer expects higher speeds.
Why would they expect this? It seems like the slowness is the only thing keeping the game from growing legs and walking away from the humans playing it.
Each one of these systems has a better replacement, but not all of the industry has moved to it.
The largest related issue I believe is that the use of “knowledge databases” by credit bureaus (and all of the companies and governments that trust credit bureaus).
Each of these has been solved, but until the last system using the inferior authentication is upgraded, they all remain weak points. I have argued that the US (or each state) should create a digital certificate system similar to Estonia’s “digital residency card” or S Korea’s online transaction signing (although hopefully not implemented as an ActiveX control for Internet Explorer 5).
The EU is actually federating systems like that under an umbrella of regulations and technical services called eIDAS [1]. I haven't been able to use it in too many places yet, but if it takes off (which is a pretty load-bearing "if", to be clear), I think it could be an important step towards making these systems usable internationally.
Especially the US, which seems to prefer to handle ID card issuance at the state or even municipal level, could benefit from a federated approach like that – assuming that people would be willing to trust their local/state government to that extent, in any case.
> assuming that people would be willing to trust their local/state government to that extent
We have too many religious people who fear government ID cards are the “mark of the beast”. We still can’t get all states to migrate to RealID, which includes a digital verification method within the ID (something stronger than a barcode).
This is mostly unique to the US. Where I'm from, we don't use our SSNs as passwords, bank checks and direct debit are simply not a thing, and credit cards have two-factor authentication for online purchases.
2FA for online purchases is, at least in Germany, is not always a thing. I don't know how it's decided, but I'd say only about 50% -70% of online purchases trigger the 2fa of my bank.
"While we are at it, when can we fix similar issues below with mainstream financial systems that millions of people are still using?"
The literal answer to your question is, no, probably not.
It's not that it's impossible, it's that a lot of the technical talent required for doing it at every financial institution that would need to, is deployed elsewhere (some of it in finance, but not in the improving-security part of it).
The lack of identifying numbers causes no end of confusion when I travel with it too, especially in European countries that Apple haven't launched the card in yet.
It got so annoying on a recent trip, I just reverted to using another conventional credit card. The Apple Card is generally fine any time I use tap to pay from the phone, but the physical card simply isn't as reliable as some other cards I have that generally "always work" abroad. I've even had restaurant staff treat me very suspiciously over the blank card.
Its also an odd card in that the physical card itself has no tap-to-pay functions at all; of course Apple want you to use the iPhone it can't operate without to do this part instead. Again though, if I do have to hand over the card, in Europe people will of course try and tap it instead of a swipe and once again confusion reigns.
Oh and if a server drops the card, it makes the most irritatingly loud clang being a small metal object - I would happily go back to plastic for the card!
I went to Europe and used Apple Card almost exclusively with zero issues. Both via Apple Pay on my iPhone as well as using the physical card. Seamless experience.
You think that is bad, every doctors office I have ever dealt with over the phone has just asked for my name, and birthdate. Think of all the friends on social media I can impersonate!
> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.
A check is simply a contract -- a promissory note. Like any contract you wouldn't sign it with someone you didn't trust, right?
(Obviously that statement, while true, is risable these days. But I remember a Bogart film in which he was setting a debt at a casino so asked the owner for a check -- he filled in not only the amount but his name, address and bank).
All the info on your check is just printed there as a convenience to you, or at least used to be. Until ~20 years ago physical checks were still sent back to your bank where they would check the signature, which could take a while! I think since the 72 hour rule went into place (and sending checks physically no longer allowed) the format was set by regulation
The check is a promise to be paid later. You are trusting the check writer that they are good for the money. The bank could refuse to honor the request if there isn’t enough money in the account or they don’t believe the document is legit (looks altered). In the not so old days* you’d have to wait for the check’s bank to accept it before you got your money.
And the writer is trusting you not to modify the check or otherwise fraudulently use the account info (in my parents’ time the check didn’t have account numbers on it so this was less of a risk).
The only backstop the bank offered was to verify the signature against the signature card and refuse the check if it looked suspicious. I think the same is still true today.
* I worked for Atari back when Warner owned them (1980s). Congress had required that companies offer direct deposit, but the minimum was they only had to offer it to you if you banked at the same bank as the company. So Atari’s payroll came out of a small bank in Sunnyvale with only one office. The rest of us got paper paychecks on Friday. Even if you went to the bank before 3 on Friday it wouldn’t be processed until Monday, which meant they’d send the physical checks to Synnyvale to be validated. Warner got to use the float on the money while all that was going on.
Me, many years ago setting up electronic payment.
-OK, it's asking me for my bank account and routing number. These must be pretty secret.
-Oh wow, they're both printed on my checks. Uh...this system works?
> Every bank check lists the bank account number, which serves as the only information needed for a party to issue a request to withdraw money from that account.
Just here point out that the issue is that it's enough to have the bank account number to issue a request to withdraw money from that account, and not that the bank accounts numbers are listed.
I can't echo the general point here strongly enough.
It's tempting to make this all "about crypto."
But crypto's just a technology. Maybe it ends up being a thing, maybe it doesn't. The fundamentals remain, and one of the present fundamentals is that (along with good old fashioned grift) stupid and terrible cybersec practices run rampant still.
I mean you’re right in that, thinking about this on an abstract level, your suggestions seem like no-brainers.
But the current system works well enough in the vast majority of cases. And the fixes to the problems you list would add considerable complexity. I don’t think it’s actually that clear that fixing these problems would have a net positive effect on the world.
The size of the market just for identify theft protection is 10 billion USD [0]. There is 30 billion USD in credit card fraud a year [1]. I don't think that is working well enough, that is a multiple-FTX sized loss of money every single year going into a problem that is fueled mostly by really bad underlying security systems.
>- Social security numbers are used as a secret for identification, despite being in plaintext and having so low entropy as to be guessable, and originally issued on a card literally saying "Not for Identification".
This is by design: millions of Americans believe that the clunkiness of the SSN protects them from tyranny.
Also in order to track UUIDs that have been received, you would either need an infinite amount of memory, or have the system bounded in terms of how many messages out of order a message be delivered and still be processed correctly.
You can use a database. Practically, most systems will keep a record of each message on disk in any case (at least they will have some logs) so it's not that outrageous. Safe to assume that the receiver can discard non-authenticated messages to avoid spam.
So you can also exchange bonds for goods and services. If you are using an interest bearing bank account, this is basically exactly what you are doing-- your dollars in the account are not actual dollars, but have been pooled into a fund that buys short term treasuries or other debt. The bank is paying you the interest on those treasuries, while taking a fee, and betting that a run on the bank doesn't render them insolvent.
I think the point to be made is that government bonds don't have any collateral baking them. For example, if a corporation has secured debt, the holders of those bonds might get first liquidation preference-- if the company can't pay its debt, the company's assets are distributed to bond holders, so you get something back. Governments have assets, but since they also have central banks which can issue dollars, in the even of a default, it seems far fetched to think government bond holders would claim government assets-- instead the central bank would just dilute its currency. This was not the case by the way in the gold standard, where government bond holders could redeem the dollar bonds and then also redeem them for gold, which would still have value outside of the failed state.
A lot of bitcoins associated with known crimes or sanctioned owners are flagged, and actually blocked by exchanges, for example there is an OFAC sanction list of bitcoin addresses. One problem with such approaches however is "dusting attacks". The owner of a blocked address could send tiny amounts to vast number of innocent addresses, thus tainting them as well. Seized bitcoins from crime have also many times been auctioned directly from authorities. So coins sold in that manner in some sense become 'legitimate' again. [1]
In any money system, maintaining fungibility is really important. You wouldn't want the distant history of a bitcoin or dollar bills to be of concern to someone transacting with it. You could probably say something similar about dollars, for example there is the famous finding that 25% of US Bills have traces of cocaine on them [2]. This doesn't make me personally feel like by using dollars I am providing liquidity to drug cartels.
