Topic: Staking Service Network (decentralized Master Node) (Read 190 times)

Sound great! Thank you for your very details explanation.

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.

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

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

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.

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 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.

Thanks, make sense!

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

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.

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.

Hi there,


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!

Another question from me.

In your paper there's content as following:


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?

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.

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

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

Hello,

Interesting idea. Can you explain more about this?


Thank you!

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.