Staking Service Network (decentralized Master Node)

[Zergity]

Staking Service Network (SSN)

So, we're redesigning the Master Node system for our stablecoin project to make it:

• More decentralized: no hard limit on entrant requirement,
• Fault tolerant: a p2p network where nodes can come and go,
• General purpose: fits for multiple services,
• Scalable: workload is evenly distributed between all nodes,
• Auditability: all service operations are recorded on-chain for audit and prevent history forging (with no blocksize overhead).

Techinical Paper: https://yggchain.github.io/ssn.pdf

We also design the Input Locking Service in the SSN to provide instant confirmation for ALL transactions, completely resistant to double-spend attack.

We need your commends and suggestions about technical design, overall performance and possible attack vectors.

Thanks.

[dvietha]

Hello,

Interesting idea. Can you explain more about this?

4. Using Rejection Sampling or Frequency Counting algorithm on the list to select a
serving node.

Thank you!

[Zergity]

Interesting idea. Can you explain more about this?

4. Using Rejection Sampling or Frequency Counting algorithm on the list to select a
serving node.

When you have an item list, with each item has a different chance to be selected, called frequency. You use Rejection Sampling or Frequency Counting to randomly pick one of them.

Frequency Counting is stacking up all the item, and count the total frequency. Pick a random number between 0 and total frequency. Start counting from the first item to pick the item located in that random number.

Rejection Sampling is to draw a frequency graph, and keep throwing dart to the board, until the dart hit the area bellow the graph.

https://am207.github.io/2017/wiki/images/Rejection.png

[dvietha]

When you have an item list, with each item has a different chance to be selected, called frequency. You use Rejection Sampling or Frequency Counting to randomly pick one of them.

Frequency Counting is stacking up all the item, and count the total frequency. Pick a random number between 0 and total frequency. Start counting from the first item to pick the item located in that random number.

Rejection Sampling is to draw a frequency graph, and keep throwing dart to the board, until the dart hit the area bellow the graph.

https://am207.github.io/2017/wiki/images/Rejection.png

So when implementing you will choose one of amongst the two methods for service node selection, right?

[Zergity]

When you have an item list, with each item has a different chance to be selected, called frequency. You use Rejection Sampling or Frequency Counting to randomly pick one of them.

Frequency Counting is stacking up all the item, and count the total frequency. Pick a random number between 0 and total frequency. Start counting from the first item to pick the item located in that random number.

Rejection Sampling is to draw a frequency graph, and keep throwing dart to the board, until the dart hit the area bellow the graph.

https://am207.github.io/2017/wiki/images/Rejection.png

So when implementing you will choose one of amongst the two methods for service node selection, right?

Yes, it actually depends on whether you can find a good enough proposal density function for the data sample. So yeah, both of them are feasible.

[dvietha]

Another question from me.

In your paper there's content as following:

A locked transaction with one input UTXO will contains up to 2N+1 signatures, and almost every transactions are locked using this service.

Then miners need to verify this? if yes, then how they can do? How miner can know/verfiy a tnx containing correct and enough signatures as the output result of rejection sampling?

[dvietha]

Hi there,

For example, the Input Locking Node can only be selected to lock an input, if its stake is no less than the input UTXO value.

If working like this then if I want to spend a small of money but I only have a very large unspent tnx output then my spending also need to wait to be locked by a big stake service node or have to wait long time to be confirmed by PoW, right?

Do you think that we can have another way to make the small spend tnx faster?

Thank you!

[Zergity]

A locked transaction with one input UTXO will contains up to 2N+1 signatures, and almost every transactions are locked using this service.

Then miners need to verify this? if yes, then how they can do? How miner can know/verfiy a tnx containing correct and enough signatures as the output result of rejection sampling?

1. 2N+1 signatures are of: sender and 2N of ILS nodes.
2. All ILS node PubKeys can be calculated by everyone using the said Rejection Sampling (all data is on-chain).
3. As part of Schnorr Signature protocol, after the first handshake round with each ILS nodes, tx sender has the list of all available ILS nodes. He will create a bit mask (each bit for each ILS node), to mark all nodes with the signature. This bit mask (takes only 2N bit, or N/4 bytes) is included in the TX, and signed by the sender and all ILS nodes.
4. From the TX bit mask, everyone will know which ILS node signatures is aggregated in the Schnorr MultiSig. So they can verify the signature with all their PubKey aggregated.

Every participant need to verify the signature, including miners and SPV, and SSN nodes.

[dvietha]

A locked transaction with one input UTXO will contains up to 2N+1 signatures, and almost every transactions are locked using this service.

Then miners need to verify this? if yes, then how they can do? How miner can know/verfiy a tnx containing correct and enough signatures as the output result of rejection sampling?

1. 2N+1 signatures are of: sender and 2N of ILS nodes.
2. All ILS node PubKeys can be calculated by everyone using the said Rejection Sampling (all data is on-chain).
3. As part of Schnorr Signature protocol, after the first handshake round with each ILS nodes, tx sender has the list of all available ILS nodes. He will create a bit mask (each bit for each ILS node), to mark all nodes with the signature. This bit mask (takes only 2N bit, or N/4 bytes) is included in the TX, and signed by the sender and all ILS nodes.
4. From the TX bit mask, everyone will know which ILS node signatures is aggregated in the Schnorr MultiSig. So they can verify the signature with all their PubKey aggregated.

Every participant need to verify the signature, including miners and SPV, and SSN nodes.

Not only verify the signature. I mean how miners know a tnx need to be locked by which selection service nodes.

For example, I have a tnx T1 and after request sampling, my T1 need to be locked by S1, S2 and S5. Afterward, how miners can know T1 have to be locked by S1, S2 and S5.

[Zergity]

A locked transaction with one input UTXO will contains up to 2N+1 signatures, and almost every transactions are locked using this service.

Then miners need to verify this? if yes, then how they can do? How miner can know/verfiy a tnx containing correct and enough signatures as the output result of rejection sampling?

1. 2N+1 signatures are of: sender and 2N of ILS nodes.
2. All ILS node PubKeys can be calculated by everyone using the said Rejection Sampling (all data is on-chain).
3. As part of Schnorr Signature protocol, after the first handshake round with each ILS nodes, tx sender has the list of all available ILS nodes. He will create a bit mask (each bit for each ILS node), to mark all nodes with the signature. This bit mask (takes only 2N bit, or N/4 bytes) is included in the TX, and signed by the sender and all ILS nodes.
4. From the TX bit mask, everyone will know which ILS node signatures is aggregated in the Schnorr MultiSig. So they can verify the signature with all their PubKey aggregated.

Every participant need to verify the signature, including miners and SPV, and SSN nodes.

Not only verify the signature. I mean how miners know a tnx need to be locked by which selection service nodes.

For example, I have a tnx T1 and after request sampling, my T1 need to be locked by S1, S2 and S5. Afterward, how miners can know T1 have to be locked by S1, S2 and S5.

By using the same request sampling process:
+ Input: ILS nodes list (from chain): S0-S1-...-S99, target block hash, input UTXO (block number & tx number)
+ Output: S1, S2 and S5

[dvietha]

By using the same request sampling process:
+ Input: ILS nodes list (from chain): S0-S1-...-S99, current block hash, input UTXO (block number & tx number)
+ Output: S1, S2 and S5

Thanks, make sense!

[Zergity]

Hi there,

For example, the Input Locking Node can only be selected to lock an input, if its stake is no less than the input UTXO value.

If working like this then if I want to spend a small of money but I only have a very large unspent tnx output then my spending also need to wait to be locked by a big stake service node or have to wait long time to be confirmed by PoW, right?

Do you think that we can have another way to make the small spend tnx faster?

It depends on the input UTXO value, not output value. And it's for your own safety. People can send a small transaction from a large input UTXO, just to double spend another large transaction with the same UTXO.

Beside, you only have to worry about this, when you are some kind of top coin holder (like top 10 or something). With that amount of money, people usually wait for several confirmations anyway.

[dvietha]

UTXO has to be signed by both current block and previous block set of nodes

If so then how a tnx to be instant confirmation as your spec if it need to wait one more block sealing; as you know block sealing by PoW take times.

[Zergity]

UTXO has to be signed by both current block and previous block set of nodes

If so then how a tnx to be instant confirmation as your spec if it need to wait one more block sealing; as you know block sealing by PoW take times.

It is instant, you don't have to wait for new block to be mined. "Current block and previous block" means "lastest block and the one before it", I might need to clarify it in the paper. Thanks.

[dvietha]

UTXO has to be signed by both current block and previous block set of nodes

If so then how a tnx to be instant confirmation as your spec if it need to wait one more block sealing; as you know block sealing by PoW take times.

It is instant, you don't have to wait for new block to be mined. "Current block and previous block" means "lastest block and the one before it", I might need to clarify it in the paper. Thanks.

Okay, I got it! Take your time to update the paper to make it clearly

[dvietha]

Can you make a summary to easy understand what is the main differences between your SSN and DASH?

[Zergity]

Can you make a summary to easy understand what is the main differences between your SSN and DASH?

SSN vs Master Node:

1. SSN is a decentralized p2p network, where everyone can easily join, while MN is widely considered to becoming more and more centralized due to the extremely high entry requirement.

2. SSN nodes can come and go as they will, while MN relies on the high availability of its nodes.

3. SSN using Kademlia DHT allows the network to scale to any level of adoptation, while MN works like a cloud service, where nodes have to keep track of each other avalaibility.

4. Every SSN operation is recorded on-chain, so everyone can re-evaluated and audit. That prevents any kind of history forging and provides the Proof of Bad Conduct for the network to punish the bad nodes. Meanwhile, MN is an offchain solution, where nothing is recorded onchain.

SSN's Input Locking vs MN's InstaSend:

1. SSN load balancing nature allow all transactions to be efficiently locked without any addition fee, while InstaSend only locks on request, with a higher fee.

2. SSN Input Locking mechanism relies on the collateralization and punishment, with 100% probability. That means, a locked transaction is either be finalized, or repaid by a bad node's collaterlized asset. Either ways, transaction receipients always get the value they are promised (by tx remitters and/or Input Locking Nodes).

Meanwhile, MN InstaSend only provides a high probability of finality. There's still chance that locked tx is double spent when 6/10 of selected nodes are compromised, and there's nothing MN can do about it.

Side Note: a prototype of SSN and Input Locking is being developed right now.

[dvietha]

Can you make a summary to easy understand what is the main differences between your SSN and DASH?

SSN vs Master Node:

1. SSN is a decentralized p2p network, where everyone can easily join, while MN is widely considered to becoming more and more centralized due to the extremely high entry requirement.

2. SSN nodes can come and go as they will, while MN relies on the high availability of its nodes.

3. SSN using Kademlia DHT allows the network to scale to any level of adoptation, while MN works like a cloud service, where nodes have to keep track of each other avalaibility.

4. Every SSN operation is recorded on-chain, so everyone can re-evaluated and audit. That prevents any kind of history forging and provides the Proof of Bad Conduct for the network to punish the bad nodes. Meanwhile, MN is an offchain solution, where nothing is recorded onchain.

SSN's Input Locking vs MN's InstaSend:

1. SSN load balancing nature allow all transactions to be efficiently locked without any addition fee, while InstaSend only locks on request, with a higher fee.

2. SSN Input Locking mechanism relies on the collateralization and punishment, with 100% probability. That means, a locked transaction is either be finalized, or repaid by a bad node's collaterlized asset. Either ways, transaction receipients always get the value they are promised (by tx remitters and/or Input Locking Nodes).

Meanwhile, MN InstaSend only provides a high probability of finality. There's still chance that locked tx is double spent when 6/10 of selected nodes are compromised, and there's nothing MN can do about it.

Side Note: a prototype of SSN and Input Locking is being developed right now.

Sound great! Thank you for your very details explanation.