Scroda solves the puzzle to concept zero-confirmation transactions.

[UnruffledST]

Bitcoin, created to disrupt the banking industry has been faced with scaling issues sinces it’s creation. Temporary solutions such as the lighting network have surfaced to provide instant like transactions to be used for micro-transactions as it is not truly secure. Leaving a need for large transactions and micro-transactions alike to be conducted in an instant like manner while being secure. Scroda being fully aware of the problem affecting all cryptocurrency users who have decided to unbank their wallets, has found the solution to implement zero-confirmation transactions through the use of relay chains.

Read more,

https://medium.com/@scroda/scroda-solves-the-puzzle-to-concept-zero-confirmation-transactions-28ed8bfd06ba

-Further Reading-

Step by step walkthrough on how Zero-Confirmation Transactions are achieved

The concept to implement zero-confirmation has been solved by Scroda realizing the need to provide maximum security to transactions. Blockchains to this day verify transactions on a block to block basis thus allowing for attacks such as the reversal of transactions through a 51% attack. This walkthrough will help you understand how through the use of relay chains, the establishment of an order-of-event, and the verification of transactions on a transaction to transaction basis before permanently being placed on the Scroda main chain allows for zero-confirmation transactions.

Read more below,

https://medium.com/@scroda/step-by-step-walkthrough-on-how-zero-confirmation-transactions-are-achieved-aa3ea86d4ae0

[1715189362]

1715189362

[1715189362]

1715189362

[seoincorporation]

I just read both articles and both forget to mention a basic issue about this, and the problem is called double spend. It has been a bitcoin vulnerability from the start, and this is why confirmations are important because double spends are a reality, so, i don't see how scroda will deal with this issue.

[UnruffledST]

I just read both articles and both forget to mention a basic issue about this, and the problem is called double spend. It has been a bitcoin vulnerability from the start, and this is why confirmations are important because double spends are a reality, so, i don't see how scroda will deal with this issue.

In Scroda we utilize a new quantum resistant algorithm called Two-Factor Proof of Knowledge a commit and reveal scheme, a user in the commit phase includes the address in which he is sending to. This prevents many common attacks.  Verifying transactions on a transaction to transaction basis through the use of relay chains and the establishment of an order of event prevents double spending from happening through a 51% attack.

Please again state how this does not seem to be prevented? did you really read through the articles? something that is even minorly mentioned in this thread.  

In order to concept zero-confirmation transactions double spend must obviously be prevented, really irks me when someone says i read x but y is not mentioned when it clearly is, did you come just to spam and increase your post count? or do you actually have no clue on how blockchain works? I don't get it, whenever I comment on something I make sure to read it and actually grasp it not so hard to do.

[seoincorporation]

Damn what a hostile replay, sorry to post in your thread y will stay away from it after these words, i promise.

Verifying transactions on a transaction to transaction basis through the use of relay chains and the establishment of an order of event prevents double spending from happening through a 51% attack.

the 51% attack and a double spend are two different things... you should know it.

really irks me when someone says i read x but y is not mentioned when it clearly is, did you come just to spam and increase your post count? or do you actually have no clue on how blockchain works? I don't get it,

You could show me where those articles talk about double spend, ho wait, they didn't mention it....

or do you actually have no clue on how blockchain works?

My doubt about how you deal with double spends (Not with the 51% attack) was because i understand how blockchain works, i know you can create and sign tons of transactions with the same inputs before broadcasting them, and if you broadcast two of them one will confirm and the other not (THAT'S WHAT WE KNOW AS A DOUBLE SPEND). and i was curious about how you deal with this. But since you get angry if a user makes a question i will just stay away from this.

[UnruffledST]

Damn what a hostile replay, sorry to post in your thread y will stay away from it after these words, i promise.

Verifying transactions on a transaction to transaction basis through the use of relay chains and the establishment of an order of event prevents double spending from happening through a 51% attack.

the 51% attack and a double spend are two different things... you should know it.

really irks me when someone says i read x but y is not mentioned when it clearly is, did you come just to spam and increase your post count? or do you actually have no clue on how blockchain works? I don't get it,

You could show me where those articles talk about double spend, ho wait, they didn't mention it....

or do you actually have no clue on how blockchain works?

My doubt about how you deal with double spends (Not with the 51% attack) was because i understand how blockchain works, i know you can create and sign tons of transactions with the same inputs before broadcasting them, and if you broadcast two of them one will confirm and the other not (THAT'S WHAT WE KNOW AS A DOUBLE SPEND). and i was curious about how you deal with this. But since you get angry if a user makes a question i will just stay away from this.

One thing is that a 51% attacks is a form of a double spend attack. What do you think happens in a 51% attack?

You can't sign and create multiple transactions on Scroda since we use a commit and reveal Scheme. In the commit stage the user has to present the address in where the funds are being sent to before moving onto the reveal stage.

There are more than one way in which a double spending attack can be peformed so you are incorrect.

You confusing a race attack as the only way to double spend is your way of thinking not everyones.

The article talks about 51% attack as a form of double spend and talks on the use of a commit and reveal signature scheme.

My comment is not hostile nor rude, I asked if you actually read the blog because you so plainly asked a question that would of been answered from actually reading the blog.

What you are is misinformed and incorrect and if me catching you on your incorrections makes you feel bad then that is your problem, when someone says I am incorrect I actually research more into it and listen, not take it as rude.

Stop trying to play the victim role it looks bad  

[Thirdspace]

I don't quite get the concept, I'm sorry if my questions don't make sense
is this mean with Scroda we will have a side (relay) chain? but real solid confirmation still on main chain?
do the same miners also maintain this 'relay chains'? locally or globally?
what happens when the once valid transaction on main chain, being used in this 'relay chains', suddenly becomes invalid?
wouldn't that invalidate all your zero-confirmed transactions on that 'relay chains' too?

[UnruffledST]

I don't quite get the concept, I'm sorry if my questions don't make sense
is this mean with Scroda we will have a side (relay) chain? but real solid confirmation still on main chain?
do the same miners also maintain this 'relay chains'? locally or globally?
what happens when the once valid transaction on main chain, being used in this 'relay chains', suddenly becomes invalid?
wouldn't that invalidate all your zero-confirmed transactions on that 'relay chains' too?

Yes the relay chain is used to commit a transaction, reveal it in another and to establish a order of event. They then get verified and placed on the main chain.

The relay chain is broadcasted to all available validators, we do not use a outdated concept of PoW still aim to utilize PoP once Scroda ID has been established.

A transaction first goes through the relay chains to then be placed onto the mainchain, a valid transaction on the mainchain would not suddenly become invalid on a relay chain as an order of event is established all transactions are processed in a specified order. The receiver can check if the transaction is true or fasle before confirmation takes places. If he checks and it is true he will be assured that it  will be processed on the blockchain, if he checks and it false and thus not be processed.

Still yes you could of worded your questions better or have been more specific.

[Thirdspace]

A transaction first goes through the relay chains to then be placed onto the mainchain, a valid transaction on the mainchain would not suddenly become invalid on a relay chain as an order of event is established all transactions are processed in a specified order. The receiver can check if the transaction is true or fasle before confirmation takes places. If he checks and it is true he will be assured that it  will be processed on the blockchain, if he checks and it false and thus not be processed.

what I mean is if a valid transaction on main chain is committed onto relay chain
then transaction on transaction happens and validated on relay chain by validators
based on scroda concept zero-confirmation I can then assume a payment is complete before it gets confirmed on main chain
but for whatever reason unfortunately the main chain gets re-orgs and that committed tx was double spent in another tx
wouldn't the relay chain becomes invalid because the committed transaction no longer valid on main chain

note: I probably misunderstood some parts of how this zero-confirmation concept works

[UnruffledST]

A transaction first goes through the relay chains to then be placed onto the mainchain, a valid transaction on the mainchain would not suddenly become invalid on a relay chain as an order of event is established all transactions are processed in a specified order. The receiver can check if the transaction is true or fasle before confirmation takes places. If he checks and it is true he will be assured that it  will be processed on the blockchain, if he checks and it false and thus not be processed.

what I mean is if a valid transaction on main chain is committed onto relay chain
then transaction on transaction happens and validated on relay chain by validators
based on scroda concept zero-confirmation I can then assume a payment is complete before it gets confirmed on main chain
but for whatever reason unfortunately the main chain gets re-orgs and that committed tx was double spent in another tx
wouldn't the relay chain becomes invalid because the committed transaction no longer valid on main chain

note: I probably misunderstood some parts of how this zero-confirmation concept works

Haha ok I prob re read your question over 30 times and am confused on how you asked it, maybe you misunderstand how this works.

A user first broadcast and commits their transaction,  then they reveal and upon doing so a order of events is established, then verification takes place.

In the way the commit and reveal scheme works a transaction is only tied to one address before and after the reveal phase.

Transaction on the main chain are permanent this isn't like in Bitcoin where a validator uploads a block, validators work together on verifying transactions before being uploaded to the block, an order of events has already been established before hand before verification. Preventing a re org attack from taking place on the main chain.

[UnruffledST]

A transaction first goes through the relay chains to then be placed onto the mainchain, a valid transaction on the mainchain would not suddenly become invalid on a relay chain as an order of event is established all transactions are processed in a specified order. The receiver can check if the transaction is true or fasle before confirmation takes places. If he checks and it is true he will be assured that it  will be processed on the blockchain, if he checks and it false and thus not be processed.

what I mean is if a valid transaction on main chain is committed onto relay chain
then transaction on transaction happens and validated on relay chain by validators
based on scroda concept zero-confirmation I can then assume a payment is complete before it gets confirmed on main chain
but for whatever reason unfortunately the main chain gets re-orgs and that committed tx was double spent in another tx
wouldn't the relay chain becomes invalid because the committed transaction no longer valid on main chain

note: I probably misunderstood some parts of how this zero-confirmation concept works

Another important thing to note is that honest nodes have a trail to follow, there is no proposal of blocks as seen in Bitcoin, Ethereum or any blockchain that verifies transactions on a block to block basis.

P.S just noted that I am 43 minutes early before allowed to bump, hopefully a mod can let this one slide.