Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe Launches L1 Blockchain: Tempo

tempo.xyz

Post reply on HN
Print view View original

611–620 of 1001 posts

Re: Stripe Launches L1 Blockchain: Tempo

#611

Post by woah »

procaryote wrote: post #234
baby wrote: post #199

Earlier quoted context omitted.

Your protocol has to use a consensus mechanism if you want to reliably make progress, and be able to recover if you make mistakes, this is exactly what a blockchain solves

That you _can_ solve it with a blockchain doesn't mean that you can _only_ solve it with a blockchain. M valid signatures of N authorities is a consensus mechanism that just needs public keys. You don't need a blockchain if you're prepared to trust a set of authorities like stripe and their trusted partners.

It's just a very unreliable consensus mechanism. Why is this being held up as a benefit?

Re: Stripe Launches L1 Blockchain: Tempo

#612

Post by spaceman_2020 »

jchw wrote: post #148
pc wrote: post #46

There are lots of crypto skeptics on HN (and we ourselves were disappointed with crypto's payments utility for much of the past decade), so it might be interesting to share what changed our mind over the past couple of years: we started to notice a lot of real-world businesses finding utility in stablecoins. For example, Bridge (a stablecoin orchestration platform that Stripe acquired) is used by SpaceX for managing…

A lot of us are not really deep into the finance space. Maybe there's a good reason it's left unsaid, but the question I came away with after reading that page and this comment is, why are businesses finding crypto easier/faster/better? To me, it's not 100% clear exactly who Tempo is for and not for, and why blockchain is more suitable than traditional centralized database technology here. And it sounds like this sys…

I sold a blog in early 2021. The seller offered to pay via wire transfer or via Bitcoin.

I chose wire transfer. Which meant going to my bank, getting approval to get paid, fill out two forms, and making three total trips.

I now have contractors in Nigeria and Philippines who want to get paid in USDT. It's instant and there is a thriving local scene of P2P sellers for instant liquidity.

Re: Stripe Launches L1 Blockchain: Tempo

#613

Post by CalChris »

DennisP wrote: post #590
CalChris wrote: post #225

Earlier quoted context omitted.

Compare and contrast L1 to FedNow. 1.5% vs $0.045 per credit transfer $0.01 per request for payment message $1.00 per liquidity management transfer Nice work if you can get it. BTW, it is crypto. So the promise that none of these businesses are using crypto because it's crypto or for any speculative benefit is a provisional promise at best. Hyrum's Law argues an opposite future.

Which L1 do you mean? I don't see any fee amounts on Tempo's page. Most stablecoin transactions are on Ethereum and the fees are neither percentages nor fixed dollar amounts. They just have congestion pricing, so it depends on how expensive your transaction is to run and how much traffic there is.

  We charge 1.5% of the transaction amount (in USD).
https://docs.stripe.com/crypto/stablecoin-payments

Re: Stripe Launches L1 Blockchain: Tempo

#614

Post by woah »

antirez wrote: post #344
stale2002 wrote: post #156

Earlier quoted context omitted.

> signing every block, to create a collaborative system that is perfectly suited for the same task. Indeed you can! We even have a name for that! Its called a blockchain. > This maintains many benefits of the blockchain and lacks many issues (fast, simple, near zero cost, controllable to a given extent -- no takeover possible, ...). Blockchains can do all of these things. Perhaps you are thinking of "bitcoin", instea…

No bizantine distributed agreement (work / stake), no blockchain. Otherwise we can name everything as everything.

There is no bright line difference between proof of stake and any other type of consensus, committee or voting body. Proof of work of course is very different.

Re: Stripe Launches L1 Blockchain: Tempo

#615

Post by sunshine-o »

wredcoll wrote: post #373
SR2Z wrote: post #368

Earlier quoted context omitted.

> At that point, a shared ledger implemented with traditional databases / protocols would be faster, easier, and more transparent. Except they are frequently _not_. I dislike crypto on principle, but you can't look at the exorbitant transfer fees and latency that a lot of banks charge for common transactions (Visa/MasterCard are especially bad) and say that crypto has no potential. Yes, it would be easier if we could…

> Why not have a central bank currency that can be traded on the blockchain, especially since converting it to real money will still entail KYC? Because literally the only point is to avoid the existing banking system and you can do that with a postures database with much less cpu involved.

> Because literally the only point is to avoid the existing banking system and you can do that with a postures database with much less cpu involved.

Ethereum is actually very low resource intensive nowadays.

You can run a validator node on a RPI, a full sync node on a Intel N100 minipc with a big fast SSD and the "light clients" can probably run on something very small.

I have seen banks having to bring semi-trailers full of diesel generators to plug them to their mainframe because the current requirements were too high for the grid during big batch jobs.

Re: Stripe Launches L1 Blockchain: Tempo

#616

Post by theptip »

dperfect wrote: post #348
pc wrote: post #46

There are lots of crypto skeptics on HN (and we ourselves were disappointed with crypto's payments utility for much of the past decade), so it might be interesting to share what changed our mind over the past couple of years: we started to notice a lot of real-world businesses finding utility in stablecoins. For example, Bridge (a stablecoin orchestration platform that Stripe acquired) is used by SpaceX for managing…

It sounds great, but every time I see this argument, I end up going down the rabbit hole of actually studying how stablecoins operate. And every time, I come to the same conclusion: they always rely on trust in an off-chain oracle or custodian. At that point, a shared ledger implemented with traditional databases / protocols would be faster, easier, and more transparent. Bitcoin (and possibly a few others) is one of…

> At that point, a shared ledger implemented with traditional databases / protocols would be faster, easier, and more transparent.

What open-source shared ledger would you suggest is a better fit?

Re: Stripe Launches L1 Blockchain: Tempo

#617

Post by consumer451 »

cvs268 wrote: post #489
allknowingfrog wrote: post #479

Earlier quoted context omitted.

Do we have a term for this phenomenon yet? Airbnb is a great example. Uber is another. Regulatory loopholes are the way that these companies actually make money, but they call it "technology" and everyone kind of shrugs.

One term for it is "Regulatory Arbitrage".

This has been my favorite SV euphemism for years.

Re: Stripe Launches L1 Blockchain: Tempo

#618

Post by stale2002 »

dmbche wrote: post #576
stale2002 wrote: post #499

Earlier quoted context omitted.

> ADDS slow clunky overhead; that's the price of decentralization. Actually, you can just use a federated blockchain. > Everything you're imagining is ALL done much easier with good ol' databases There is an ecosystem of 10s of thousands of developers that can run specifically ethereum contracts on a database, while being compatible with all existing stable coin onramps? You have to show me the 10s of thousands of de…

What are the tens of thousands (?) of devs doings that is more efficient by doing it on a blockchain is the question Hint: the point of "proof of work" is to do more work than necessary

> that is more efficient by doing it on a blockchain

Well one major thing is what I just brought up that is more efficient thing is the developer experience.

Being able to fork an open source integration that has all of these money and smart contract features built in is much easier than trying to figure out how to design a smart contract system from scratch that doesn't use a blockchain.

Re: Stripe Launches L1 Blockchain: Tempo

#619

Post by westurner »

jazzyjackson wrote: post #508
menzoic wrote: post #481

Earlier quoted context omitted.

>At that point, a shared ledger implemented with traditional databases / protocols would be faster, easier, and more transparent. This is missing the fundamental idea behind blockchain. You need a consensus mechanism and immutable ledger in order for it to be secure and truly transparent. Once you add those boom you have yourself another blockchain :-) >So what are stablecoins really trying to do? Circumvent regulati…

> You need a consensus mechanism and immutable ledger in order for it to be secure and truly transparent Consensus between who? The stablecoin issuer, stripe in this case, is a single party, who are they coordinating with that requires a consensus algorithm?

How does centralized SQL replication do consensus, compared to a DLT?

Blockchain consensuses: Which is the next block, Which protocol version must what quorum upgrade to before a soft fork locks in, Whether a stake should be slashed, Leader/supernode election (handled by the UNL text file in git in rippled, which underpins R3, W3C Web Monetization micropayments, and W3C ILP Interledger protocol (which FedNow implements)),

When there are counterparties and then they might as well just off-site replicate the whole database or blockchain locally, and run indexes and queries at their expense.

And then there is a network of counterparties willing to grant liquidity to cover exchanges that cover multiple assets and chains, who want to limit their exposure by limiting the credit they extend to any one party in the network and account for an entire auditable transaction. (Interledger ILP Peering, Clearing, and Settlement)

Private blockchain or SQL replication scaling woes? And then implement mandatory keys in an append-only application.

This or something like Trillian?

From "PSA: SQLite WAL checksums fail silently and may lose data" https://news.ycombinator.com/item?id=44672902 :

> google/trillian adds Merkle hashes to table rows.

> sqlite-parquet-vtable would workaround broken WAL checksums.

> [...] [cr-sqlite implements CRDT, which is one of a number of newer ways to handle consensus in SQL database replication ]

> (How) Should merkle hashes be added to sqlite for consistency? How would merkle hashes in sqlite differ from WAL checksums?

Re: Stripe Launches L1 Blockchain: Tempo

#620

Post by stale2002 »

kiitos wrote: post #580
stale2002 wrote: post #504

Earlier quoted context omitted.

> Are you claiming here that things like banks and stock markets don't exist? No, I am claiming that I couldn't spin up a bank or a stock market on my laptop, that is compatible with all the other stock markets, by forking a git repo. > that have no non-crypto counterparts, are you referring to? The git repo fork button, that slots right into a whole ecosystem that has 10s of thousands of contributors to it. Ease of…

> No, I am claiming that I couldn't spin up a bank or a stock market on my laptop, that is compatible with all the other stock markets, by forking a git repo. yeah, and that's kind of very much by design -- regulations that prevent this kind of yolo nonsense are a feature and not a bug

> and that's kind of very much by design

Ok, so then Yes I have brought up a valid and in demand usecase, you just don't like it.

Yes the point of all of this stuff is to make this usecase easy. Thats a real usecase. You just don't like that its easy.

Post reply on HN