/biz/ - Business & Finance

The idea that software somehow dictates how many transactions a system can process per timeunit is complete bogus.

Hardware and network dictate those things.

Think about it like this: How many emails per second can Outlook send? Does this question make any sense, or does it really depend on your computer and internet connection? It certainly does.

The same is true for distributed systems. The network that links them together and the servers that operate it are the deciding factor.

Since Stellar (and by design, also ripple) is a permissioned system, the operators can easily and contractually bindingly upgrade the hardware and network to increase throughput. This is why a permissioned system can "scale" by investing in better hardware, while an open system (e.g. btc/eth) cannot. They simply don't have a mechanism to force anyone to provide better physical machinery.

>>11036104
scaling in crypto is about algorithm bud, not machines.

Their version of lightning offchain network is rolling out next month. This will also cause a token burn

>>11036321
*Wheeze*

>>11036321
this is only true for proof-of-work systems as they rely on the protocol to remain inefficient to some degree. In more classical byzantine-fault-tolerant environments this is not true (at least to some degree - obviously a faster algorithm makes a faster network. Yet there are certain theoretical maxima that have been reached since the early 2000s)

Relevant reading https://eprint.iacr.org/2016/199.pdf

If your experience in distributed systems is from reading non-scientific and non-peer-reviewed whitepapers put out by private entities you shouldn't make strong statements about these things. btw

>>11036394
>this is only true for proof-of-work systems
You mean the only system that actually works?
I love that smarter people than me aren't able to see basic facts because of their own hubris.

>>11036458
>You mean the only system that actually works?
elaborate how non-PoW systems do not work, if you're that educated

>>11036482
Elabourate how they do? There is currently no pos system with a track record of security.
Which one do you know that has been running for multiple years and has survived serious attack?

>>11036587
There are dozens of permissioned algortihms that have been in operation for about 35 years that provide strong security guarantees.

E.g. Asnychroneous consensus as propsed by Ben-Or 1983 https://allquantor.at/blockchainbib/pdf/ben1983another.pdf (Note: Not asymptotically optimal)

>>11036633
Wow that sounds great. Which decentralised. censorship resistant permissionless currency has been using that for 35 years?

>>11036677
the us dollar. How do you reckon banks handle their servers, brainlet?

>>11036685
>decentralised. censorship resistant permissionless
>the us dollar
Huh. I didn't think I would win this one so easily. I'd say gg, but you know....

>>11036721
>decentralised. censorship resistant permissionless
you don't realize that proof of stake presupposes FIAT currency, do you? That means it's not decentralized per design.

You also don't realize that PoS - as you surely realize simply translates to holding-bound-permission - isn't permissionless. Exactly the contrary to be precise.

Bank servers are decentralized. It's generally multiple for redundancy.

The thing you are asking for is logically impossible. Hence it does not exist.

>>11036765
Like, how can you know those words and arrange them like that? How can you be so smart and dumb at the same time?

It genuinely excites me to see posts like this. Logic says that it should be impossible for poor people without connections to make better returns than educated rich people, but I see so many educated rich people putting SO MUCH EFFORT into being wrong, and then rationalising that wrongness. It's delicious.

https://www.stellar.org/blog/lightning-on-stellar-roadmap/

>>11036835
How about you produce some arguments rather than asserting that I am wrong?

>>11036851
Nah I thought you were smart. Go argue with the other brainlets.

>>11036880
I'm supposed to write a thesis on asynchronous byzantine fault systems right now (in case you were wondering why exactly I had papers on that topic at hand that quickly) and I'm willing to do anything not to.

>tfw my degree can wait to argue with autists on the internet
>tfw I'm the autist

>>11036050

They have yet to hit scaling limitations - and ledger close times are consistently ~5 seconds. The balance a trusted network concept with a level of decentralization (not fully decentralized, and not fully centralized) to with quorum slices to agree on ledger state to ensure this ledger close time will scale - Stellar consensus protocol. They claimed 3k+ tps about a year ago, but who knows until we see true adoption + transaction volumes nearing that on the live network.

So, my question is 'stellar isn't fast enough' for what transaction volume - you say exchanges + payments, but that's a very vague statement? Give a number of tps to hit.

Also, second level protocols (lightning) is being introduced to obfuscate transaction volumes between two known entities - but will also have the effect of greatly reducing the transaction volume of frequent transfers between two entities on the network - thus reducing the tps the network has to handle.

>>11036903
Back to your wage cage normie!

>>11037103
I'm unironically a fulltime student

>>11037152
Man your knowledge is precious
What's the best coin that resolves the Bizantine fault problem?

>>11037355
They all do, that's kinda the point of the whole thing

>>11037371
So also the banks are decentralized?

So what's the real difference between banks servers and crypto?

>>11037466
So to make things as simple as possible:

You want several servers to maintain the same state. Either within a certain timeframe (synchronous) or with an eventual guarantee (asynchronous).

Problems arise when servers die (crash fault) or become malicious (byzantine fault). A byzantine fault tolerant system can deal with either. You can probably already see how this is something that a bank would value. Even if one of their servers is hijacked it cannot willy-nilly wreck the whole system. That's why any mission critical system interally runs a BFT consensus algorithm.

Crypto is different in the way that the servers don't all belong to one entity. This is where the Sybil attacks come into play. Allowing anyone to simply add more servers (and therefore network share) allows them to control the whole network.

To combat this the ownership is either bound to a buy-in (PoS) or some computationally complex task (PoW) that guarantees that attacking the system is more expensive than the potential payoff.

>>11037466
monetary policy is a big difference, as well as distribution logic and ownership properties. the dollar is only close to being fully ownable (permissionless ownership) as paper currency, which can be detected in transport and physically seized. bitcoin is transportable as a memorized 12 word phrase and plausibly deniable

>>11037545
This is one of the most interesting things ever

So 99% chances are that Satoshi Nakamoto was just a a bank programmer with lots of experience, am I right?

nobody can prove you wrong. stellar like ripple are both build on ancient blockchain tech, and will need massive changes to be even close to usable.

they're both vastly more inefficient than bitcoin is per transaction, so they also need more resource usage to get the same throughput.

>>11037607
kek

Man >>11037545


Is this guy >>11037607 right?

>>11037584
Hard to say. Satoshi was the first one to envision a BFT system that doesn't simply rely on identity, but rather ties it to computation. This simple fact alone allows anyone to participate in the network. That's something classic systems just can't do.

Although (argueably) a freaking dumb system on paper, it was the first one to allow for a public ledger by preventing the Sybil attack problem. In some ways it is ingenious, as it doesn't play by the rules of classic BFT theory. God knows what sick fuck Satoshi is. My best bet is that it's actually a group of people with pretty diverse backgrounds

>>11037628
no. Proof of work strictly prohibits statements like "per-tx efficiency" as the blocktime needs to stay constant through difficulty adjustment. Adding more computation power to the BTC network doesn't make it faster in any way (see https://www.blockchain.com/en/charts/hash-rate?timespan=all))

>>11037607
>they're both vastly more inefficient than bitcoin
don't listen to him, bitcoin maximalists are cancer
>>11037628
xrp and stellar are ready for production use TODAY

>>11037715
I took it as a tongue in cheek post criticizing OP. Out of all the network options out there designed around value transfer, xrp + stellar are production ready and have real utilization with scalability handled. BTC has some huge issues when thinking of it as a vehicle of transfer as opposed to a store of value.

>>11036880
>>11037103

stop shitting up threads with your lack of knowledge

>>11037957
stop shitting up the thread with verbose lack of knowledge