FreshAir08 @FreshAir08

@HighTrustCrypto @KaspaSilver @KaspaUK @fengtality I don't know why you are acting aggressive, and I specifically don't know why you act aggressive towards me.

@anbrandenburger @NikolaGalilei @KaspaSilver This is a mempool standard, not a consensus rule, it can change at a whim, by a community decision, with or against devs wishes, no need for a fork.

@Max143672 @Free_data0 Do I gather correctly you manually implement PQ signatures using the new opcodes? Impressive we can actually do that definitely.

@HighTrustCrypto @KaspaSilver @KaspaUK @fengtality read here: gist.github.com/michaelsutton/…

b) its fixed because it will be "broken", well not broken, but spamming does put a strain on node runners and the ecosystem. When this load is due to actual demand, everyone is happy with being overloaded, but when its due to someone abusing the absurdly low default fee, less so. The fork would exacerbate this phenomenon if we had done nothing, nothing would have "collapsed", but it would have mean people could regularly strain ecosystem barely any price.

@DesheShai To the best of my knowledge its also not true - the default has not changed. Regardless anyone could use p2pkh today, its just that wallets need to change to support it and make it the default.

@p4bpj @coderofstuff_ @manyfest_ @michaelsuttonil Probably not. FWIW anyone can use it as is to derive pochm's right now, its not a HF feature, just some node infra Its a good point it will likely require some mild updates following KIP21.

The short answer is that the explorers were measuring things in a flawed unaveraged manner. If at some particular second, you had 4 full blocks instead of the average 1 block, you had got 1200 tps. At other times you can have by chance only 1 block in 4 seconds, (so only 75tps). The correct way is to average these fluctuations out. You can see a relatively detailed answer on Kas's actual (current) limits here qa.kas.pa/posts/44/48#an…

@zerogaig3r @BTCBreadMan @Dr_Gonzo_K @grok Kaspa Tps is at max about 2800-3000 currently. Neither is it really accurate that btc at max is 7tps. This is just an average figure, which hides in it some transactions in disparate sizes. and while wer'e at it, 10bps not 1bps. don't give grok credit it don't deserve.

@NikolaGalilei @DesheShai I cannot process all of this, I'll just ask you - in what sense are "DAG properties" currently maintained when M<C?

The short answer is that there is no reason the blocks should be "deterministic". This is easier to reason on the scheme descirbed in gist 1. The idea of punitive schemes is to simulate the same behaviour in practice as the non punitive ones, without the glaring downside. Is there discussion to be made if that is really what would happen? absolutely. But one cannot begin this discussion without understanding what it is we try to achieve - i.e. lets please agree on the qualities of gist 1 first, and whether your questions apply there.

> I think that interim solutions should be doubly and triply criticized for long-lasting disadvantages. For the record, others had suggested we revert to pay your bid when "adoption" occurs, but I do think this direction has the potential to be robust always, even though more analysis must be done. Regardless, the discussion on its disadvantages is wide open. > I'd say that if Kaspa's TPS in the "infinity limit" is 100, then it did fail. And if it didn't, then it is still more natural to create say 100 one-transaction blocks per second than to implement LSZ. What if its only there for 1 year? What if normally there is 100tps but once per day that there is a 2 hour burst of 20000tps? Every real market has fluctuation in demand. > ...then essentially you are introducing a lot of complexity for a mechanism that is relevant for about a single order of magnitude Security budget is not a theoretical discussion, it has clear implications here and now. The assertion that adoption comes in an all or nothing form is one I cannot get behind. The world may not be linear, but it is equally absurd to assume it is a dirac delta step function. I think you are being very "best casey" in your tps calculations btw (all transactions with ~1kb payload for example), but regardless, why is a single order of magnitude meaningless? >I think that generally, what rubs me the wrong way is that LSZ was designed to provide affluent dynamics in the face of scarcity, which is the opposite of Kaspa's "normal" operation Scarcity in what? it always seemed to me that LSZ describes precisely the situation in Kaspa: how having an unlimited blocksize should not harm the fee market. The way I see it btw, Kaspa decoupled security from capacity, and it is a natural next step to attempt to decouple fee market from capacity. These two things should not be dependent of each other, we should not limit ourselves in increasing throughput because we think it might harm the security budget. If there is demand, miners should profit from it. That you consider reducing supply (BTC style) as a better solution is a surprise to me. And again "as needed" is incredibly subjective, you don't suggest we hardfork for it every month right? it has to be some form of an automated process. > Perhaps I misunderstood your second gist, but it seems that you are using an form of bidding aggregation for penalizing non-monopolistic prices. I'm a bit challenged by your disparate terminology to truly understand the core of your criticism. But for the record - I'd be happy if we can first clear up what you think of the first gist, which is much easier to reason about. I against the world, will still argue that the breaking tradeoff within it, is well worth it.

> Kaspa is meant to be a high TPS system. If it is indefinitely stuck in low TPS, then it failed its purpose. If it constantly admits high TPS, then your mechanism becomes superfluous. Sure, but do you not recognize the value of a mechanism that extracts value in the mid term? If we have 10000tps in the system than security budget is a non issue, and because of Dags, same if we have 2000tps. But what if we have constant 100tps in the system? constant 100tps may not be "global adoption", but neither could it be considered to have failed its purpose completely. This is not an unrealistic scenario in the short term, and I would expect miners to be able to extract some noticeable value from tps in that field. Yet under the current mechanism - these transactions will still bid 0.0001 kas. With my (first) proposal, I'm actually very optimistic regarding the upward pressure's effect on the security budget. > Moreover, as you stated yourself, your construction relies on bidding, and it is unclear to me that current anticones are large enough to provide sufficient non-gameability. I agree with your assertions on the asymptotic, but I reckon that the usable regime might very well require increasing BPS as it is. I actually don't understand what you say here, could you please clarify? > I don't think that decoupling block sizes from fees is crucial for inclusive chains like Kaspa, since there is a lot more control over block size to rate tradeoffs. The lower bound on the required TPS, as you said yourself, is "linearly" dependent on block size, which gives more control. I'm not sure I follow this suggestion, do you suggest we HF to reduce the blocksize in favor of bps? I'm sure you're aware of the non-triviality of increasing bps, let alone the rigid nature of such a decision. (as a sidenote, there is at times a need for singular big blocks, namely starks are a well discussed usecase) > That being said, even if the block size limitation seems instrumental, adaptive block sizes (like the ones @maxibitcat suggested) seems like a more promising route to me. I don't rule out these types of solutions, not from a practical point of view anyway, and we have discussed them actually. But the problem is how the blocksize is determined and who or what effects it, and this seems to me far more gameable/ error prone really.

@ronment3 @michaelsuttonil @Max143672 @asaefstroem Not sure if you are the same person as discord, but anyways: t.me/kasparnd/1/102…

@hashdawg_ @coderofstuff_ All that was removed was metadata regarding the blocks. i.e. it is completely recoverable from the headers and bodies (which were left untouched), but regardless its really not the type of data you would ever care about.

A thank or two to finish of: Obviously @michaelsuttonil who directed me at this and guided me alongside @coderofstuff_ , and also @elldeeone who helped me diagnose where the bottleneck in pruning really is at.

Updating on a PR of mine merged to master: github.com/kaspanet/rusty… TL;DR computing data relating to the pruning proof on the fly while building the proof rather than all the time results in substantial performance optimization on many fronts. A word or two for the unacquainted: theoretically speaking, all you need to know to follow a blockchain consensus are block headers and block bodies, if your node stores those locally, anything else you possibly want (to verify a new block, to know what can be pruned, to answer RPC calls) is implied by that. It is however preposterous to recompute stuff from scratch all the time, so in practice (in all computer science, not just blockchain), you more than often store a lot of “metadata” with the goal of making computations shorter at each step of the way. In Kaspa one prominent examples of such metadata are the various “per block” stores - databases containing certain types of info on every block (indexed by the block’s hash). Moving on: As you know in Kaspa there is a Dag structure and each block on it is assigned a blue score - a parameter somewhat equivalent to block number in btc. What is less famous is that there are actually multiple Dags in Kaspa - derived from the main one. Simplifying a bit, what you should imagine is that in these “higher level” Dags, blocks whose hash difficulty is not rare enough for that level are filtered out, and instead of the now hanging edges, new edges are accordingly shortcutted between great grandparents and great grandchildren. These are known as indirect parents, and they are written out in block headers for every level out of the possible 225 (It is worth noting though that most levels are regularly empty or contain very little parents). Additionally, each such Dag also implies a per level blue score for the blocks in it. Without diving into much detail, these high level POW representative but sparse secondary dags allow us to quickly compare the POW accumulated by two diverging DAGs without being forced to always store all blocks since genesis. For this comparison, what we require is the blue score of the blocks of the secondary Dags. In the far far past precrescendo, we computed the blue score for every block in the network on all possible levels, and stored it in such aforementioned “per block” store. In practice however, most of this data is of no real relevance - the levels in the pruning proof are by design themselves “pruned” to about 2000 headers, as it is the higher and sparser levels that form the significant part of the proof. Ergo a past PR by @coderofstuff_ improved performance by opting to compute the blue score of the higher levels only when generating/comparing a pruning proof. And yet, this on the fly computation of the blue score still left a remnant of per block X per level storage. It was a thing called relations_store. What the (level i) relations_store gives for every block is quick access to its “children” on that level. While the indirect parents of the level are directly derivable from the headers the same does not apply for indirect children. This store facilitated forward traversal of the DAGs, which was useful when calculating the blue score. The point is that children are ultimately still implied from the Dag structure and thus a satisfactory relations_store can be reconstructed on the spot by doing one backward traversal of the DAG on that level. Doing this only while building the pruning proof, and only for a small number of blocks, meant we no longer have to regularly maintain relations at every level. The effects did turn out to be dramatic - first, archival nodes reported a significant decrease in storage usage. Second, header processing became a lot more efficient without the need to write these new stores to the disk. The effect is that the Kaspa node is lighter on your PC - but of no less important is that the header stage of IBD became a lot faster. I am not sure if I should give figures, because every machine is different, but for me it was about an x3 difference. Finally, not storing these higher level relations also meant you don’t need to erase them during pruning. As it turned out - this was a big bottleneck during pruning, which my personal laptop had a hard time with, and is finally relieved from.

@NikolaGalilei yes and yes, you have to make L1 help you in some manner if you truly want to use its properties. (Computation Dag - structurally, not the actual contents of each vertex, this is an important distinction)