 Show Posts
|
|
Pages: [1] 2 »
|
Are you sure you have read what i wrote: Avalanche: "Avalanche is a DAG-optimized consensus protocol–high-throughput, parallelizable, and simple to prune." And I said we also use block lattice DAG... So you are saying avalanche is not a L1 protocol??? Only blockchains are L1 protocols??? Hmm🤔 Complex DAGs are great for some things and bad for others, like smart contracts, because linearity requirements ... That's why avalanche added a "normal" chain as you call it... But still I don't really think you understand what a DAG is... Please read this, it might help you understand: https://twitter.com/FantomFDN/status/1354095234301489152?t=me91hn1J_EKAdMq25lzTfw&s=19 |
|
|
|
|
You would do this for every transaction in the block. Or just the winning one?
But basically this is stil PoW, as far as I see it.?
|
|
|
|
So it's really a robust protocol. Not cheating like Avalanche with this randomized sampling, which will probably cause them major syncronization problems down the road.
I can see that. But how come avalanche got cheating on their randomized sampling? I read some text about it and also Im not so deep with regards to their tech but somehow they have a working protocol at the moment which already up and running. I cam see potential on what you enumerate, but until we can see this running like avax then dont drag their project as if yours are still in the process of theoretical right? Thanks for the reply. I am not really bashing avalanche. Just explaining their shortcomings. Usually, in Practical Byzantine Fault Tolerance (pBFT), you need at least 51% or 50%+1, votes to confirm a decision. They decided that 5,10 or 20% is enough as the probability is high enough that a consensus will be reached. This was done for speed and decentralization. Although the system might work in normal conditions, the system still has potential attack vecors and synchronization issues that might be discovered only with more load and traction. Especially in the case of network partitions, where an attacker can force where the votes should be coming from. The design sounds very risky... Our system has normal 51%+ voting, speed is gained with vote re-usage and compression and delegation. And we have a demo testnet so it's not theoretical. |
|
|
|
Building a layer 1 protocol. Most similar to Avalance and Nano. If any guys willing to help please message me.
We have a working prototype and are 10 years plus IT and security specialists with PhDs, so we are not dreaming in clouds...
Can you showcase the project concept or at least a brief introduction you are building here aside from you mentioned it same like avax and nano. Btw you needed help? Or you are outsourcing for a job like marketing or developer side. If its like that pitch to service announcement and post properly like you are looking for one to work for you. Yes. Project is flinkcoin.org. It's got a new dPoV, delegated proof of vote consensous alggoritm, and the block lattice structure from Nano. Some of the features: -Block-lattice DAG -dPoV consensus (delegated proof of vote) -Parallel sync chain -Predefined smart contracts -Voting packet-based distribution -Multisig -No fees -Payment reference number -Payment requests -Time-limited transactions (now or never) So it's really a robust protocol. Not cheating like Avalanche with this randomized sampling, which will probably cause them major syncronization problems down the road. |
|
|
|
We are working with some local exchanges. Will try to post also to other sections. Maybe will have more success. Thank you! |
|
|
|
|
For a exchange you will need 250k easily.
BR
|
|
|
|
|
What do you mean by backer? And what are you devloping.
|
|
|
|
|
Building a layer 1 protocol. Most similar to Avalance and Nano. If any guys willing to help please message me.
We have a working prototype and are 10 years plus IT and security specialists with PhDs, so we are not dreaming in clouds...
|
|
|
|
|
Nowdays most crypto project go the venture capital route. Unfortunately for venture capital you will need good connections. It's hard to get capital without that
|
|
|
|
|
If you control the tokens. Then you partially centralize the whole procedure also it's not permissionless anymore. Basically, you get stocks:)
|
|
|
|
|
The best coins are L1 layer protocol ones. If they really provide some new tehcnology. This almost always rise. Others it's really speculation.
|
|
|
|
|
The adoption might be slower. But as the population is increasing the demand could still be high. But it might not be a game changer.
|
|
|
|
|
Solena, ethereum, avalanche... Surebets with reasonable return.
|
|
|
|
|
It's the community-building part that takes time. Without a community, nothing really works...
|
|
|
|
|
That's probably the worth of Binance. And CZ might be the sole owner.
|
|
|
|
|
Buy them when they are down:) Try to watch for a period where the price has platoed for some time. Often there is a reversal coming.
|
|
|
|
Its True but can't agreed with whole statement cause long term investment in top altcoins, could also reasonable cause most of those always follow bitcoin rally but rest of altcoins could be risky for invest cause there's always chance to scam or turn into shitcoin in long run. Short time trade may profitable with altcoins but hype coins could be risky because sometimes they never come back on that position, from where you buy but you can do short trades if you can fit with those facts.
Yes, long term only in the top icons might be safe. But you have to do periodic check ups... |
|
|
|
|
Maybe wait for a week or two. The market is still transitioning. Then first the surebets: avalanche, solana, ethereum, then then alts...
|
|
|
|
|
Solana fees are very low. You have also Nano which is feeless. But they do have some network problems occasionally as does Solana. I am the author of flink which will be zero fees, but will also enable custom tokens.
|
|
|
|
|
Securing the network or protecting against DDOS is very hard with small fees or no fees. Eventually they will figure it out. But if you are a pioneer you will need to solve issues not seen before.
|
|
|
|
|
