Author

Topic: Sub-Second Zero-Confirmation Transactions (Read 275 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
July 18, 2019, 01:17:11 PM
#12
1. Possible bug due to use of 2 blockchain all depends on how well coded the blockchain is, scenarios due to bugs are scene in any blockchain in which does not take the time to have their code properly audited. sidechains and mainchains have been around for a while thus removing such concern, it works, it is proven to work if coded right.

You're right, but complex system usually leads to various kinds of bug. For example. Solidity bug keep found even though it has been around for years & have lots of contributor.

Look into the article, we are updating the whitepaper you will find it to be outdated in the zero-confirmation transactions section. Also we will be removing alot of unneeded content in the whitepaper.


I'll read it later after it's updated
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
Would you be able to clarify these trade offs?

pooya87 already said most things i thought, additionally :
- Concern about possible bug due to use 2 blockchain with different variable/usage altogether
- Concern about attack towards leader and committee members (who have votes) which could halt the network
- Possibility 1/4+ fraction of votes intentionally halt the network 

P.S. i haven't looked the details of the system
member
Activity: 243
Merit: 18

You're right, but complex system usually leads to various kinds of bug. For example. Solidity bug keep found even though it has been around for years & have lots of contributor.

Yes more complex systems will lead to various bugs, a two-chain system is not complex, building a dapp in a turing-complete language is set to allow for many bugs to pop up.
member
Activity: 243
Merit: 18

pooya87 already said most things i thought, additionally :
- Concern about possible bug due to use 2 blockchain with different variable/usage altogether
- Concern about attack towards leader and committee members (who have votes) which could halt the network
- Possibility 1/4+ fraction of votes intentionally halt the network  

P.S. i haven't looked the details of the system


1. Possible bug due to use of 2 blockchain all depends on how well coded the blockchain is, scenarios due to bugs are scene in any blockchain in which does not take the time to have their code properly audited. sidechains and mainchains have been around for a while thus removing such concern, it works, it is proven to work if coded right.

2. There could be no attack towards leaders that would be benificial to the network, we do not use committee members this is seen in ThunderCore but in Scroda we do not have the use of a centralized commitee in who can vote, concensus is fully decentralized all the leader does is establish an Order of Events. They do not validate or confirm orders. Plus leaders are rotating in a extremely rapid speed in near sub-second time.

3. 1/4 of votes would not halt network as leaders have not votes, concensus is fully decentralized.

Look into the article, we are updating the whitepaper you will find it to be outdated in the zero-confirmation transactions section. Also we will be removing alot of unneeded content in the whitepaper.



Quote
A rotating leader is elected in which establishes a order of events,

can you explain these two concerns a bit more:
- how is this "leader" elected (based on what criteria)?
- and how do you fight Sybil attacks where a malicious entity controls a large number of these identities that can be chosen as "leader" and can accept fake transactions as "confirmable"?


Quote
Honestly I am probably a bit hostile as no one in the community likes to talk about new idea's because they feel butthurt that someone beat them to it.
i think most people (who aren't in it just for the money) are weary of seeing lots of new projects all claiming they are the best with new innovations. and you know it takes a lot of time to investigate each of them to see if they are actually telling the truth or was it just an advertisement. and after a while when you checked dozens and got disappointed, you simply give up and don't take anything seriously unless there is something real good going on with that project.

1. Leader is established in a randomly predetermined order through the use of the mainchain.

2. Leaders have no power in confirming transactions all they do is establish an order of events on when they saw a transaction come in. Confirmation and Concensus all takes places on the mainchain in a fully decentralized manner.

Leaders are just essentially leaving a paper trail in which can be followed when consensus has to take place on the mainchain. These will be confirmed to be true or not in a fully decentralized manner in where transactions are verified on a transaction to transaction basis and not a block to block basis thus preventing attacks such as reversal of transactions through a 51% attack since a malicious user can not just choose to upload their own malicious block.
legendary
Activity: 3472
Merit: 10611
Quote
A rotating leader is elected in which establishes a order of events,
can you explain these two concerns a bit more:
- how is this "leader" elected (based on what criteria)?
- and how do you fight Sybil attacks where a malicious entity controls a large number of these identities that can be chosen as "leader" and can accept fake transactions as "confirmable"?

Quote
Honestly I am probably a bit hostile as no one in the community likes to talk about new idea's because they feel butthurt that someone beat them to it.
i think most people (who aren't in it just for the money) are weary of seeing lots of new projects all claiming they are the best with new innovations. and you know it takes a lot of time to investigate each of them to see if they are actually telling the truth or was it just an advertisement. and after a while when you checked dozens and got disappointed, you simply give up and don't take anything seriously unless there is something real good going on with that project.
member
Activity: 243
Merit: 18
still you never mentioned that it was not secure.

Fair point

We are working on our testnet, paper will come with it, article is in the first post of this thread. Did you read it?

I did, but looks like it only explain part of the protocol/system.

We build upon proven solutions. A rotating leader is elected in which establishes a order of events, we utilize two chains a side chain and a main chain in which the side chain is used to establish an order of events thus providing scalability and the main chain is used to confirm transactions thus providing security. Look at Solona and Thundercore. All we do is take a different approach to be able to obtain a secure enviroment in which we are able to implement sub-second zero-confirmation transactions. Surpassing Solona and ThunderCore's vision. ThunderCore and Solona both lack heavily as a sole blockchain, that being that ThunderCore does not obtain full scalability they utilize a commitee in which they are only able to obtain 5-10k TPS, Solona is only a blockchain based on Scalability no security thus being able to obtain 500k+ TPS still not being able to provide true security as they are decentralized.

It's interesting idea, but few people including me doesn't like the idea due to trade-off.

Would you be able to clarify these trade offs?
member
Activity: 243
Merit: 18

I never mention 0-conf is secure, stop making baseless assumption.


It's what I took from your statement

"0-conf has been around for years, even though usually it takes few seconds due to latency and propagation across multiple nodes."

You mentioned it being around for such a long time without mentioning it not being secure, if a new comer looked at that statement all they would see is oh 0-conf has been around for years and it is fast due to latency and propagation across multiple nodes, still you never mentioned that it was not secure.


I doubt there aren't any trade-off, but if it's true, could you show us the paper or article about it?


We are working on our testnet, paper will come with it, article is in the first post of this thread. Did you read it?

We build upon proven solutions. A rotating leader is elected in which establishes a order of events, we utilize two chains a side chain and a main chain in which the side chain is used to establish an order of events thus providing scalability and the main chain is used to confirm transactions thus providing security. Look at Solona and Thundercore. All we do is take a different approach to be able to obtain a secure enviroment in which we are able to implement sub-second zero-confirmation transactions. Surpassing Solona and ThunderCore's vision. ThunderCore and Solona both lack heavily as a sole blockchain, that being that ThunderCore does not obtain full scalability they utilize a commitee in which they are only able to obtain 5-10k TPS, Solona is only a blockchain based on Scalability no security thus being able to obtain 500k+ TPS still not being able to provide true security as they are centralized.


How did you come to that conclusion? I was talking about sub-second 0-conf you shared.

On a different note, 0-conf & LN was used only on micro-transaction (with few other strict criteria) with assumption where attacker, scammer or theft think it's not worth their time or effort.


The conclusion was pretty obvious "even though usually it takes few seconds due to latency and propagation across multiple nodes."

Still if you are agreeing with me that if my project is feasible then it is a need then thank you. Yes current solution only allow for micro-transactions to take place as they are not truly secure.

Honestly I am probably a bit hostile as no one in the community likes to talk about new idea's because they feel butthurt that someone beat them to it. Bunch of money-hungry folks that do not contribute to others, we see communities where some got their 15 seconds of fame and are willing to help the other as they are already well established but no in this community it is very rare to see such case. For someone to try to help someone build on their ideas or help them see the flaws in their project so they can fix on them, etc.
member
Activity: 243
Merit: 18
0-conf has been around for years, even though usually it takes few seconds due to latency and propagation across multiple nodes.
CMIIW, but the main reason sub-second 0-conf is possible due to less propagation & most nodes uses fast connection.

It looks like people are only interested in crap in this community, new tech doesn't interest no one here what a shame.

It's because you make this thread on Project Development which isn't popular.

0conf has been around since the begining of bitcoin if you want to be technical but it has never been secure, why do you think we see moves to the lighting network which at the same time is not secure also, 0conf can be seen also in Bitcoin SV but it is not secure.

Yes 0conf has been around for years but it has never been secure enough for mainstream use. This being true in all blockchains who verify transactions on a block to block basis.

Someone with 1.6k post should know that the 0conf that have been around aren't secure.

Edit: Also at the same time those who have 0conf transactions do not have scalability, and those who have scalability do not have security so there has always been a trade off.

We obtain both, scalability and security 500k + transactions while still having 0conf transactions.

This community keeps on disappointing me day by day no good convos to be found anywhere.

Edit 2: reading your comment again you then state 0conf through the use of a semi-centralized network, thus no security obtained you must be hinting towards the lighting network. Really you call that secure Huh
member
Activity: 243
Merit: 18
It looks like people are only interested in crap in this community, new tech doesn't interest no one here what a shame.
member
Activity: 243
Merit: 18
Say YES to sub-second zero-confirmation transactions and say NO to instant confirmations.  

The Sub-Zero Protocol permits Scroda to achieve Sub-Second Zero-Confirmation Transactions all due to two chains coming together and becoming one, Yin and Yang.

https://medium.com/@scroda/scrodas-sub-zero-protocol-walkthrough-c1677f3d60fa
Jump to: