Šťoural
3.7K posts
@Audit1000
Think independently. Nokia's market share fall from 49.4% in 2007 to 3% in 2013 shows how crucial adaptation is. One block per 10 mins – is it enough?
@beffjezos As soon as the first news breaks that a quantum computer has cracked a bank account, I'll set a timer for 10 years to start worrying about BTC.
Time preference might be the most underrated concept in the world. It shapes how you eat How you spend How you work How you save And whether you can even understand Bitcoin.
I finally did some research on Bitcoin vs Kaspa. Here’s what I found. Mega thread below 🧵
People keep trying to compare Bitcoin to dial up internet, saying there are new coins like Kaspa that are high speed and “better tech”. My question to you: If “better tech” always wins, why hasn’t every faster coin replaced Bitcoin yet?
Flood and Loot attack on the LN This post follows the paper arxiv.org/pdf/2006.08513 written by Aviv Zohar et al. (AFT 2020) This paper focuses on a wide systemic attack, in which an attacker triggers the closure of many Lightning channels at once. The resulting high volume of transactions in the blockchain will not allow for the proper settlement of all debts, and attackers may get away with stealing funds. Preliminaries In the lightning network, the trustless nature ensure you can interact with the blockchain in order to reclaim funds if another party is cheating you. The goal of the attack is to have everybody try to access the blockchain and post transactions there at the same time, which will cause a congestion. This is done by running the attack in parallel on a large number of victims. We start the same way as for the congestion attack. We connect to a victim from two sides and send a large amount of payment request from one attacker node to the other. On the channel, there are now a large amount of HTLCs waiting for the secrets to be sent back in order to complete the payments. Here is an image for intuition, Now the RHS attacker node sends the secrets back, and once they are shown to the intermediate node (the victim), it behaves naively and simplifies the transaction. Given he knows the RHS has all the secrets, he just replaces the transaction by updating the balances, giving him the money without the need for all the HTLCs. Once that is done, the RHS channel is closed on the blockchain as the attacker simply has a small transaction that can be easily included into a block. The victim then expects the next node to do the same thing, a simplification of the transaction. But then, the attacker on the LHS stops interacting with the channel and goes silent, he refuses to sign a new transaction. Now this shouldn’t be a problem right ? The victim already has the secret, so he can just redeem the funds by sending the LHS transaction with all the HTLCs to the bitcoin network. However, for the channel to be closed, the large transaction has to be accepted into a block. Furthermore, the victim has a limited amount of time to do so, because the HTLCs expire after a few hours. After that, they are useless and he has lost his funds. The attackers get the money from the victim, through the RHS tx, but the LHS attacker never paid him. The funds have successfully been stolen. So how do we ensure the victim doesn’t manage to redeem the transaction by sending it to the blockchain. This is done by causing a congestion of the blocks. If the attacker execute the setup in parallel many times, there will be many victims with large transactions competing with one another to make it to the blockchain. Given the limited space in each block, if the attack is conducted at a large enough scale, some victims won’t be able to redeem their funds, and the attackers will pocket them. The victims fail to recover all the funds due to congestion of the blockchain. Here is a visual example of how a parallel attack would be executed The final nail in the coffin There is a quirk in the LN that amplifies the above attack. To understand it we have to look at what happens when a channel is opened between Alice (the attacker) and Charlie (the victim). An HTLC is issued from Alice to Charlie. Charlie sends back the secret, and now tries to claim the money by publishing his commitment as the expiration hight approaches. Once expiration has arrived, Alice then published a transaction saying the HTLC has expired, hence trying to claim back the funds. Now Charlie published it first so he will be included first right? The subtlety is that the HTLC-success transaction has to be signed by both parties. This means that when it is created, Alice pre-signs it in advance, thus promising to pay a certain fee. If Alice goes silent, Charlie cannot change the fee associated to the HTLC-success transaction. However, Alice doesn’t need Charlies signature when the contract expires, and can claim the funds back through an HTLC-timeout transaction. She can increment the fee and thus have priority over Charlie. But Charlie went first, so he should still be fine right? Wrong. If the attack is conducted on many victims, the HTLC-success transactions congests the network. Priority then goes to the highest fee. If Alice was smart enough, she created all these contracts when fees were low on the bitcoin network. So many transactions with low fees are fighting for inclusion. Alice then arrives, posting HTLC-timeout transactions with much higher fees, frontrunning many victims in the process. The funds have been stolen.
This weeks article (last weeks) on @KaspaCom is now live. I was intending to write on something totally different, but KIP21 popped up on X, I went down that route, and was very busy this weekend... So the article digs into KIP21... kaspa.com/learn-kaspa/po…
The case for the uniqueness of fast pow tl;dr Finality has two moving parts: (i) fast inclusion (= high bps, how quickly a tx gets into a block), and (ii) fast confirmations (= how quickly that tx becomes irreversible). Any system with rapid block production can achieve the first. The second is where the tension shows: in pos, fast confirmations press directly against decentralization. In fast pow, the two properties are decoupled. prologue A few weeks ago I came across Solana’s founder claiming: “Solana is the fastest monetary system in the world”. Since Kaspa already runs at a faster block rate, I was curious to check Solana’s finality times. That curiosity quickly pointed me to a deeper issue: not raw speed, but how speed interacts with decentralization. —————— The tension is structural. In pos, finality means accumulating staked votes, and the more decentralized the stake distribution, the more time is required to reach finality. Here I’m not talking about hardware requirements or validator specs. The axis I’m discussing is centralization around the security mechanism itself: stake in pos vs. hardware in pow. To be secure, a block must be confirmed by a supermajority--typically >66.7% of the total economic stake. In a truly decentralized network, where n stakers with uniform share grows without bound, the time to coordinate this supermajority becomes a real bottleneck. Pow works differently. It samples the hardware space without requiring the protocol to explicitly collect evidence from a majority of miners. Each block is itself a statistical proof that the finder out-competed the full network’s hash power. This process--and its timing--remains independent of how many individual miners participate. Ethereum’s researchers understood this when moving to pos. Unlike Solana, which tolerates concentration to reach ~13-second finality, Ethereum’s designers could not accept that trade-off. Their solution was to introduce rotating committees. A rotating committee is a smaller subset of validators, randomly chosen from the full set, that votes on behalf of everyone else. But this comes with a different security model, known in the literature as exposure to a BFT adaptive attacker. The committee is selected first and then votes. That “select-then-work” sequence is theoretically exposed to adaptive attackers, since members are known in advance. Pow, by contrast, is “work-then-select”: the winner is only revealed after the work is done. Think of it this way: in pos, you know who the referees are before the game starts, which gives an attacker time to pressure them. In pow, you only learn who won after the work is already done, which removes that attack surface. So n confirmations provide consistent confidence regardless of miner granularity, and the system stays secure even under adaptive targeting. Beyond attack subtleties, the real issue is economic weight. When I send a billion-dollar transfer in a pos system, the question I care about is simple: how much stake is actually securing it? A committee vote provides strong statistical evidence, but only a true supermajority puts the full economic stake of the network behind my confirmation. In other words, a sampled committee may convince me that things are probably safe, but only the weight of the entire stake provides an overwhelming guarantee. And this is exactly where pow shines: each confirmation is not just a probability estimate, but a direct proof of work done against the full hash power of the network, no matter how many miners there are. closing remark I don’t claim to know every engineering detail of Ethereum or Solana. But I’m convinced the core principle holds. I’ll state it simply: fast pow uniquely enables fast finality without forcing a compromise on decentralization.
$kas Kaspa won't survive without tail emissions. In fact it's impossible to create a low fees currency without inflation. Kaspa's inflation is going down and security is plunging to 0 along with it. It's mathematically impossible to sustain Kaspa's security with low fees.
