FreshAir08

Kaspa researcher and developer.
Supported by the Kaspa ecosystem foundation (KEF)

[FreshAir08 @FreshAir08]

I honestly disappreciate the rhetoric here altogether.

"Would you rather have money serving your interests or a moralless code?

Would you rather have money used for crimes without repercussions or money supervised by law?

Would you rather a no man's land where scammers get away, or a world where the weak and vulnerable are protected?

Do you prefer good things or bad things?"

And respectfully this isn't even the tip of the iceberg, if we consider how the technology actually is in the real world. If you need me to fill this section up - tell me.

I know twitter's bad formatting and inherent penchant for "good and bad" simplification, plays a roll here, but
the first step in having an honest debate, is not flattening the argument - DLT, inherently, has downsides compared to fiat. You may think these downsides are worth it, you may hold to a world view where these downsides are the way the world should work, but presenting only the positives of DLTs without even mentioning the built in flip sides of these very properties, without mentioning a single disadvantage of the technology, and pretending you had any meaningful discourse, is just bad culture of speech.

[FreshAir08 @FreshAir08]

@OriNewman Can you link here the first token mechanism implementation side by side with the modernized version?

[FreshAir08 @FreshAir08]

Static scripting is ultimately less expressive than "regular" smart contracts, and it comes with certain downsides and certain upsides. In practice though - it is challenging (not impossible) to come up with a usecase that silverscript/argent won't be sufficient for.

On the long run - I still believe vProgs are the correct architecture for full blown computational scaling, but on the short run, Silverscript definitely lowers the pressure considerably and lets things mature at the right pace.

[FreshAir08 @FreshAir08]

@KaspaSilver that said, their claim of "completely solving security fee crisis"...

Meh. Cut down on the hyperbole add more justification and analysis.

[FreshAir08 @FreshAir08]

@KaspaSilver First time I heard of it, and will read on. Generally, I absolutely think any new POW coin should be forking Kaspa rather than btc, and we should see it as a complement.

[FreshAir08 @FreshAir08]

@OriNewman @manyfest_ @IzioDev @michaelsuttonil @asaefstroem I'm astounded by what silverscript has become. When I was initially explained covenants I thought it to be some necessary check mark so Kaspa could have simple vaults.

I cannot believe the extremes y'all pushed this too.

Community - the ball is set - your move now.

[FreshAir08 @FreshAir08]

@brt2412 @KaspaSilver @OndoreVillager @ghostofstacks lets invite ghostbanned lol

[FreshAir08 @FreshAir08]

< KAS' own documentation makes it clear that 'K' is related to block rate, network delay and the probability bound being targeted. When you increase the block rate, you have to account for the increased amount of parallelism.

Ultimately BSV and BTC, too have assumptions regarding network delay. And at least for BTC these assumptions are true, and IMO actually overly conservative. I don't know how it fares in BSV. But yes we assume a certain network delay and so do you. Bitcoin security, is ultimately also dependent on some assumptions.

What you should ask is are our assumptions correct and representative - and they are. The network delay taken in practice is taken with a rather large margin of error, (which as a sidenote is what DK aims to resolve). K is configurable based on blockrate, and network delay.

If you are asking - can we have infinitesimally short block rates, not currently barring more research to make a few more things efficient. But we have been able to make it short to the point where the dominant factor in confirmation times is almost exclusively (the bound on) network delay. We already have bps shorter than anyone have believed 6 years ago, making tradeoffs not in the atmosphere of what BSV did, and while it does get arguable if we need to - we likely can go shorter still without too much repercussion.

This discussion is orthogonal to throughput - we can do so keeping same throughput, and we can increase throughput even without doing this by just making blocksizes bigger. Either has effects, no one is denying that - but mitigating these effects, is itself important and worthwhile. Nothing is magic, but it does not mean things shouldn't be improved as much as possible.

[FreshAir08 @FreshAir08]

Satoshi comments - thanks for the direct quotes.

I too am human and am getting tired - I might try to give this more attention later, but generally, I think you are extrapolating the god out of everything he said. There is a huge jump between "not everyone will run a node" to "near no one will be able to run a node", as there is an important distinction between running a node to verify network, to running a miner, which I think at least some of the quotes talking of specialized hardware allude too.

Here is another Satoshi quote FTR:

"I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions."

Now 15 is technically less than 100k, but I think this gives a different perspective to the numbers he had in mind.

[FreshAir08 @FreshAir08]

Mega TPS:

I'll try to keep it short, I had these convos before: Ultimately you know 1M+ tps goes against anyone but a select few being able to run nodes and verify the network. Fine. I think you are wrong and we'll argue over this in a different comment.

I think L1 should not be used for infinite throughput as it goes against decentralization, and it is not what we are aiming for.

We are aiming for enough throughput to be a financial backbone of finance, on top of which other layers are built on. What is the exact number for it? times will tell, but its not 7 and not 20. But ff you think the number is in the billions then I argue you are no longer in the buisness of decentralization. if you want trad fi trust assumptions, use trad fi.

Last point regarding this - since you support 0 conf - clearly you still think users should be able to see the mempool right? in the gigantic throughput you have in mind, even that is absurd - are users to have in their machine a billions sized mempool? and they are to constantly scan it? Or is even 0-conf confirmations delegated to trust in a select few?

[FreshAir08 @FreshAir08]

> Ultimately, I think the KAS 'crew' are getting caught up in comparing one number — (confirmation time) — when there are several different things that need to be considered.

Besides Data BW, which I simply tell you, I have no intention to go to the outrageous 1M+ tps route (we probably can do around 30k rather easily though if we don't have to think of fee market issues) , what are these things we don't consider? can you point out any more metrics in which BSV is better?

[FreshAir08 @FreshAir08]

If we want to keep a semblance of sanity, we probably need to separate talk to branches:

Hashrate: sure btc has much more economical hashrate than KAS has. How does BSV compare there? is this really a fair point?

If you want to attack KAS because it has trouble breaking through from the initial conditions and accumulate economic hashrate comparable to btc, sure good for you, but
(a) this is hypocritical of you
(b) Every network starts with 0 hashrate. When you design a network, you argue for how it fares as a worldwide global network used for decentralized finance. When you try to onboard people from the 0 hashrate to gazillion hashrate, you convince them by arguing over the end goal.

This is not to say the mid term is not important, and does not require thought and effort to go through and grow, but it just has nothing to do with the protocol's qualities.

Of course we should be comparing protocols themselves, under the same assumptions, this is the discussion.

Finality: Pruning is not a major reason, it is the reason, and of course I'm pretty sure BSV has a variant of it. I don't get where you are going with this besides pointing "ha ha you technically have hard finality", who cares? no one is supposed to use this as a measure of acceptance, and it only exists because we have to prune.

[FreshAir08 @FreshAir08]

BSV has made huge, rather trivial sacrifices on decentralization, to achieve huge throughput. Is anything you do a novelty . To my knowledge, bsv is the only pow to take things to these extremes, You cannot be calling Kaspa "behind" because it remained more or less with the overall market ethos while bsv took tradeoffs that no one else in the market would consider decentralized. You saying you confirmation times, and waiting for 6 blocks, is unimportant, contrasts to the analysis done in the wp, and contrasts to the fact that POW was needed to achieve what is achieved.

I think we should try something - can you explain to me, why you use POW and not POS? cause if, as you subtly claim, your security relies on the economic repercussions of foul play, then I don't see a diffrerence. In fact pos is in some respects better as it has it baked in protocol.

That is to argue, on some level, on some point, you must acknowledge confirmations are important. You must acknowledge 3 block aboves are better than 2, which are better than 1, which are better than none.

Otherwise, you don't really believe that pow is necessary.

And if you recognize that confirmations are important, you must recognize its better for those to arrive within 15 seconds than 1 hour. I personally, never thought any of this is interesting so long as I need to wait 1 hour. And if you suggest me alternate security models based on trust and accountability, well I'll rather take the original over the copycats - trad fi works on these assumptions already.

So now, say again for the sake of it, that I accept your choice of BW, and I offer you a magic trick that will allow you to have way faster confirmations without sacrificing anything, will you really reject it? I argue that GD, is very close to this "not sacrificing anything", and am curious why won't a very unconservative coin discuss making a substantial improvement when it presents itself?

[FreshAir08 @FreshAir08]

Ultimately your ethos seems to be the point of contention, so let me preface by saying - yes, I think that your vision would not count as decentralized not only to 90% of the market, but also to Satoshi himself. You are essentially suggesting very, very few entities (10?) being the only ones remotely capable of verifying the network, and being able to do with it as they want. and further, are saying that you don't really care of the analysis of pow in the btc paper. To me this alone points out absurdity and distance from the original vision.

> You don’t seem to get that Bitcoin was intended to be large server farms of honest nodes controlling the majority of hash-power, as Satoshi explained

Please quote Satoshi saying something of sorts, I highly doubt this, and further doubt your extreme interpretation of this. There is a huge space between "everyone should be a miner!!!" (which Satoshi indeed didn't think nor say) to "a single digit number of corporations should be able to run a full node" which you seem to be supporting de facto by talking of 1M+ tps.

Here is an excerpt from the btc wp:

"Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification."

Is this in line with your vision?

> Economic incentives to “defraud” a transaction only matter if the expected gain realistically outweighs the risk and cost. For ordinary payments that threshold is almost never met.

As I explained, neither me nor the miners, lose anything in btc terms by attempting the attack. Internally to the system, the attack actually always pays off in expectance, regardless of the amount. Your counter, is, as I expected, relying on external devalue or accountability.

> Even if you somehow were, other honest nodes would quickly see the conflicting spend and reject it.

This is wrong - they won't until I mined the double spend privately, by which point it should be too late. Are you advocating they censor the longest chain based on something ephemeral they saw on the mempool?

> As a result, you'd be held accountable and risk your entire business in doing so. The incentive to remain honest is the profit-generating mining operation/business itself.

So, should I not read it as you resorting to trust, kyc on the miners and legal accountability? if we want to rely on accountability, why not do it nowadays? what's wrong with ripple, or swift, or banking in general? If we want legal accountability, do we also accept these 5 miners being legally bounded to censor txs by the US government? legally bounded to reverse blocks?

[FreshAir08 @FreshAir08]

What happens if they never take the cash to the bank?

What happens if a tx never makes it to a block?

That is to say, I find your example very flawed.

The cheque is somewhat a better example, as you can arrive to the bank and realize that whoops, there actually isn't money to back it up (somewhat analogous to a double spend).

Let us be concrete and realistic: say I buy meth from my dealer for 1000$. I send the tx along the ether, he sees it on the mempool and gives me it all. I then contact a miner, and asks him to mine an alternate spend of my funds, I'll pay him 100$ for it. Maybe he won't succeed. but what does either of us have to lose? What if I'm a miner myself? can I walk around the world freely double spending?
I can guess ahead of time your response will be some meta like "well rational miners won't devalues the value of his own holdings by making them unreliable", well sure, but this applies to fiat as well no? and somehow big holders still cheat steal and scam. It is naivity to think a coin can replace fiat and not have people regularly try shit like shit like this.

I can give more examples, more flaws, honest backfires, etc. Do let me know if I need to repeat all my objections to 0-conf in specific, I've grown a little tired of it, and assume you've heard them before. If you have something written down, we can at least save all of us some time.

Side question, I assume BSV does not allow RBF?

[FreshAir08 @FreshAir08]

We use probabilistic finality and no one says otherwise. Probabilistic security is the backbone of cryptography - there always is the chance you can just decrypt the digital signature of my address by pure luck. The question is what is the probability of it. In that regard the difference from 0-conf to 6 btc blocks confirmation is heaven and earth - even though I personally would argue the security there is still too small for my taste. FWIW, Kas guarantees roughly the same security within 15 seconds.

The 12 hours "hard" finality in Kaspa is side effect of needing to prune that I'd personally gladly throw under the bus if we could FYI.

> The original idea was never “every hobby laptop has to be a full consensus machine.” It was large, skin-in-the-game operators running serious hardware, staying honest because their business quite literally depends on it.

You are fully entitled to disagree with Satoshi, but to claim your version is the original idea is completely out of line with my impression of the btc wp.

> “If the only limit is physical resources, that’s a good thing” is a cope

Look man, this has been the Kaspa stated since inception, criticize what you will, but please acknowledge Yonatan et al very well knew what they were aiming at when doing the research.

> “Show me an attack that doesn’t also work on Bitcoin” misses the point. The question is how easy the attack is. High-frequency DAGs give attackers more room to mess with what different peers think the recent graph is. That is a real networking and consensus issue.

There is some point in which you have to stop speaking abstractly. Do you not think high frequency and DAGS are things people thought of? do you not think they are analyzed in the security proof? At the consensus level, GD is secure, and the graph ordering settles quickly in the same manner in which the btc longest chain settles "quickly" (with the corresponding high block times). We have the math to back this claim up which you can read in the paper. If you have another attack in mind, be concrete.

> That’s before you even get to what a transaction can carry. Kaspa is still tight on size and script.

Come on man, we can build chess fully on kas without scratching the surface. Are covenants Turing Complete? no, and I thought this would be a limitation but I was proven wrong, covenants are very, very expressive and It is not very easy to find a crypto usecase that cannot be done with them. IMO From now on, if people want to claim something can't be done with covenants, the burden of proof is on them.

Final question: I assume you understand that bsv's huge bandwidth has downsides, but you just claim that they are worth it. Let's for the sake of the argument, say you are right. But why not incorporate Ghostdag adapted to your preferred BW and still get both your desired BW and lower conf times? There could be legitimate answers, but I am somewhat curious, given BSV is clearly not very conservative, why not adopt well tested novelty?

[FreshAir08 @FreshAir08]

Well why even use blocks then? Why even use pow? just send your tx through the ether and everything will be fine right? If what you said was right we could have had btc in the 80s.

Respectfully, I reject your view completely and shout it from the top of the Everest. This is pow-blasphemous.

[FreshAir08 @FreshAir08]

@BSVCasey @OriNewman @BTCTKVR @Vladcostea @kurtwuckertjr I will never get this sentiment where "complexity" is something to be scared of.

Sure Kaspa is more complicated, so what? its more complicated because it scales down confirmation times to levels unheard of in pow. Of course some ingenuity was needed for it.

[Michael Sutton @michaelsuttonil]

started to record a short 10-min live-coding argent episode: a basic multi-actor ticketing app.

one hour later, episode 01 exists 😅

start here:
https://t.co/Hjb9Tksypu

written code:
https://t.co/qdI40DaIoX

[FreshAir08 @FreshAir08]

@KaspaSilver Silver I admit to not knowing much about this but I applaud you for pushing yourself on the technical side like this.