Paper: Transaction Locking and Masternode Consensus

This new development has the potential to change the game.

I have a question about transaction limit. If I am not mistaken, currently bitcoin has 7 transactions per second limit. If Darkcoin is going to compete with credit cards, how will this new development affect Darkcoin's transaction limit per second?
 
tungfa said:
Sounds Amazing !
Great work, thank you guys.

I might need a "translation" (into simple language)
please !

I understand 'instant transactions' ... and then ?
can somebody please pm me !?
tx
Click to expand...
It just means your transactions go through very fast almost instantly and there's no chance for an attacker to accomplish any double spending. That's what I understand.
 
tungfa said:
Sounds Amazing !
Great work, thank you guys.

I might need a "translation" (into simple language)
please !

I understand 'instant transactions' ... and then ?
can somebody please pm me !?
tx
Click to expand...
TanteStefana wrote a very good explanation in bitcointalk:

Wow, I just finished reading.... um, let me try...

when a person wants to spend coins, they tell everyone (broadcast) and put a lock on the fund in their wallet. The current group of masternodes receives this information, and when they all verify the same information (validate it), they let all the other clients on the network know it is so. This takes only seconds and the coins are then considered "cleared"

If the person spending the money tries to send conflicting information (tries to spend the coin twice, by paying himself the same coins= double spending attack, which they could code into their wallet so it happens really fast) the conflicting information will cause the masternodes to reject the lock, and the coins spent will have to wait to go through the mining process to be validated. (one will be accepted, the other rejected as it is done currently) This will also happen if one of the masternodes that were elected to do the work ends up losing connection (or tries to pull something).

This makes 3 types of attacks virtually impossible to commit.

Wow
Click to expand...
 
Probe said:
Are dropping the whole block-chan algorithm ?
Click to expand...
No! The proof of work (mining) is still too strong to give up. However, it does allow us to lengthen the time between solutions (finding blocks) which in tern lowers the bloat of the block chain. I just have one worry. If a masternode loses connection, then the lock is void and the transaction must go through the POW (mining). If we make the solved blocks too far apart, it could really become a problem when a person wanted to spend their coins on something NOW and has to wait a half hour or an hour. Could the void simply kick things back, and make a person resend instead? Rather than wait to be sent for proof in the mining process? It would be more like getting an error message instead of confirmation, so that they can try again. I think that would be much more usable and doesn't leave anyone hanging.
 
Even if you invent a holy grail of the crypto, them btc fanboys will call you a scam and a shitcoin. Once the markets abandon btc to have anonymity, the real demand of btc will drop. It's a matter of time.
 
jpr said:
Even if you invent a holy grail of the crypto, them btc fanboys will call you a scam and a shitcoin. Once the markets abandon btc to have anonymity, the real demand of btc will drop. It's a matter of time.
Click to expand...
Scam is the most overused word in crypto... you can't even ask what time is it without someone shouting scam.
 
Last edited by a moderator:
thelonecrouton said:
LOL, I burned some karma (well done nj47!) but it's wasted effort - BTC zealots are curiously blind to technical innovation, perhaps because they have all forgotten what innovation looks like.
Click to expand...
Indeed. They're crushing Bitcoin's creativity, but it won't matter in the end. Their time is passing. Crypto will win with or without any further innovation from Bitcoin. We can thank them for their contribution then race forward without them.

c9xo6.jpg
 
TsuyokuNaritai said:
Indeed. They're crushing Bitcoin's creativity, but it won't matter in the end. Their time is passing. Crypto will win with or without any further innovation from Bitcoin. We can thank them for their contribution then race forward without them.

c9xo6.jpg
Click to expand...
LOL nice picture.

Anyways, can someone head over to this thread and start working with me on a press release for tonight?
Thread: https://darkcointalk.org/threads/po...ns-kristov-code-review.2399/page-3#post-21361
Pad: https://titanpad.com/sG3qI9tiby
 
eduffield said:
[...]Full paper can be read at the link below:
https://www.darkcoin.io/downloads/InstantTX.pdf
Click to expand...

eduffield, I think the combination of very long confirmation times (10 minutes) and the fall-back strategy to the standard confirmations if a lock is incomplete opens a couple of DOS vectors.

Masternodes could be DDOS-ed, or even worse maliciously refuse to vote to slow the system down (remember there _are_ people having 50+ Masternodes, so the chances are quite good to have at least one Masternode in the voting list). And people _will_ try to slow down the Darkcoin network for several reasons.

My proposal is to add redundancy to the Masternode list, e.g. select 20 (instead 10) Masternodes, use the first 10 Masternodes as you would now and if one of those 10 nodes fails to vote (for whatever reason) after a given time-out invalid this node and delegate the vote to Masternode 11, then 12, and so on.
 
crowning said:
eduffield, I think the combination of very long confirmation times (10 minutes) and the fall-back strategy to the standard confirmations if a lock is incomplete opens a couple of DOS vectors.

Masternodes could be DDOS-ed, or even worse maliciously refuse to vote to slow the system down (remember there _are_ people having 50+ Masternodes, so the chances are quite good to have at least one Masternode in the voting list). And people _will_ try to slow down the Darkcoin network for several reasons.

My proposal is to add redundancy to the Masternode list, e.g. select 20 (instead 10) Masternodes, use the first 10 Masternodes as you would now and if one of those 10 nodes fails to vote (for whatever reason) after a given time-out invalid this node and delegate the vote to Masternode 11, then 12, and so on.
Click to expand...
Hell, select from a fallback list of 50. Or all of them. One-line change in the code, not sure how it would add to network chatter?
 
Last edited by a moderator:
crowning said:
eduffield, I think the combination of very long confirmation times (10 minutes) and the fall-back strategy to the standard confirmations if a lock is incomplete opens a couple of DOS vectors.

Masternodes could be DDOS-ed, or even worse maliciously refuse to vote to slow the system down (remember there _are_ people having 50+ Masternodes, so the chances are quite good to have at least one Masternode in the voting list). And people _will_ try to slow down the Darkcoin network for several reasons.

My proposal is to add redundancy to the Masternode list, e.g. select 20 (instead 10) Masternodes, use the first 10 Masternodes as you would now and if one of those 10 nodes fails to vote (for whatever reason) after a given time-out invalid this node and delegate the vote to Masternode 11, then 12, and so on.
Click to expand...
I have similar concerns and was thinking along the same lines.

Perhaps it would also be possible to select 20 authority masternodes outright and require a minimum of 10 votes for a consensus quorum. If votes >=10 and rejects=0 the tx lock will succeed.
 
Last edited by a moderator:
kryptofoo said:
I have similar concerns and was thinking along the same lines.

Perhaps it would also be possible to select 20 authority masternodes outright and require a minimum of 10 votes for a consensus quorum. If min_votes >=10 and rejects=0 the tx lock will succeed.
Click to expand...

I was worrying about the same thing, it's the one thing that jumped out at me as a problem in the paper. If you need 10/10 masternodes to work, and each masternode has just a 1% chance of not performing it's function (it could be a bad actor, or have network issues, or DDOS, or whatever) that's a 9.6% failure rate! That assumes independent probabilities, but even so... :eek: It's a lot smaller if you only need a super-majority to work.
 
crowning thelonecrouton vertoe kryptofoo TsuyokuNaritai

The problem here is to find equilibrium between a low probability and high impact event (double spend), and a higher probability and lower impact event (fall back to block confirmation system). It is true that a super majority or a redundant list would greatly reduce the probability of the fall back, but it would increase the probability of a double spend by forging the lock. In the super majority system because you need a lower percentage of the selected masternodes. In the redundant list system because the attacker could DOS selected masternodes that are not his so he has a new chance to get one selected.

I'm out of town in a weeding for the weekend, but I'll think about it to run a few numbers next week.
 
Dummy Translation:
(I asked for this personally)

1. Thank you TanteStefana
when a person wants to spend coins, they tell everyone (broadcast) and put a lock on the fund in their wallet. The current group of masternodes receives this information, and when they all verify the same information (validate it), they let all the other clients on the network know it is so. This takes only seconds and the coins are then considered "cleared"
If the person spending the money tries to send conflicting information (tries to spend the coin twice, by paying himself the same coins= double spending attack, which they could code into their wallet so it happens really fast) the conflicting information will cause the masternodes to reject the lock, and the coins spent will have to wait to go through the mining process to be validated. (one will be accepted, the other rejected as it is done currently) This will also happen if one of the masternodes that were elected to do the work ends up losing connection (or tries to pull something).
This makes 3 types of attacks virtually impossible to commit.

2. Thank you fernando
If someone tries to double spend by trying to send two conflicting transactions, only one will be deemed valid by the current group of masternodes and the lock will be in place. That transaction will later be mined, but it is already valid because the miners will check the lock. The one without the valid lock will never get into a block because it conflicts with a valid lock. The payee that did not receive the validation can wait for block confirmations because maybe it is a rare case of valid transaction that has not been validated (rogue masternode or network problems), but he will know from the beginning that there is something wrong and can wait to release goods or services. Double spending not possible
 
You must log in or register to reply here.
Back
Top