Topic: The feasibility of shadow-coins by PoW / Layer 2 (Read 169 times)

just afraid I didn't express the data flow of shadow-coin very well.

the second layer of PoW in shadow-coin processing just affects the block header of the main coin, so verifying transactions in detail will follow the principles of the main coin. RandomX or any other suggested algorithms only work with small amount of data same as Simplified Payment Verification (SPV) [1] needs to get done..

I suggest RandomX just because it enforces to provide CPU which is necessary to spread high quality nodes along a peer-to-peer networks. We need an economy running in that layer and this may increase the bitgold layer cap of any coin that equips by shadow-coin mechanism.


References:
[1] https://bitcoin.org/bitcoin.pdf / page 5

RandomX is the worst possible choice for preventing DoS attacks, as it is very expensive to verify.
A good PoW should instead offer instant verification, so the verifier's time cannot be wasted.

True.. it seems this could be something beyond a weakness and severity of such fake-nodes could be a problem for shadow-coin. so after a little modeling and reading current accepted weaknesses in peer-2-peer networks [1]:


I ask myself while we are dealing with such problems in current technology, this would be good idea to improve them all together:


and while fake-nodes are going to steal the processing power of other nodes, scoring is good idea and fits the situation of shadow-coin..

when a full node goes to act as a mining-pool for other incoming nodes, you should provide a db to write valid shares of each incoming node for any possible winning shadow-coin and pay them via lightning e.g. in future.[2] and as there is no guaranty for a miner to have her revenue back in mining world but connecting to famous and trusted pools around the Internet, after a while anonymous full nodes could get identified by their behavior in two groups of trusted and untrusted categories - but this time the trusted one preserves herself by second layer of PoW..

and still thinking..  

References:
[1] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
[2] https://en.wikipedia.org/wiki/Lightning_Network

Here is how a fake/semi-fake node would work, and I'm using bitcoin P2P protocol which should be similar to any other coin too.
You can write a small code with minimal functionality that connects to other nodes and gets the needed number of blocks or block headers only. This code doesn't care about validity of those blocks so the cost of verification is 0. This code also doesn't need to store those blocks so the cost of storage is also 0. The amount of data it downloads is also minimal (a handful of blocks compared to all blocks). So it can be run on the same machine through some sort of proxy to have different IP addresses and appear as multiple nodes.
Then to solve the PoW problem all it has to do is to use that small amount of data it downloaded to compute the hash. It could also reuse part of that hash depending on the algorithm to compute it for other instances. For example
Instance1:

Instance2:

Using SHA256 this would be 2 blocks to compress, the first block of each round is the same (first 64 bytes of header) the second block is different so even the job is cut in half for 2 instances which is encouraging this kind of behavior.
[RandomX may prevent this last part but I'm not familiar with the algorithm to give a solid opinion.]

this feasibility study really needs such questions to see if it is worthy enough - thank you Pooya..


making it harder to perform a sybil / DoS attack [1] against nodes [2] in a blockchain system should be the main reason of such suggestion. in other hand, while we could limit the number of incoming / outgoing peers - this may look useless to have extra protection layer for classic attacks as we face in web servers e.g. but in our project, we have some master nodes among other full nodes, so I always had this problem to find a rational way to have a routing system among peers to balance loads and mitigate some shapes of attacks mentioned above..

now, here we are! master nodes (or any other nodes based on many reasons behind their experiences in running a full node) could define their own policy to ask an incoming connection for a higher or lower difficulty to solve. a full node could write extra policies for its outbound connections too. for example, pick a node with high difficulty after every 100 low difficulty outbound connections.


people could turn it off or connect to nodes with zero difficulty, but we all know accessing to pure information costs. and actually this is why this new layer of PoW should end to a shadow-coin to encourage people to pay and buy good hardwares to run more reliable full nodes.  


it was about distinguish incoming/outgoing connections of peers. sorry for misinformation..  


true. I hope I have explained it a little more above..
but despite of encouraging people to run a full node, there is always doubts/dispute over those full/mining(Block-Producing) nodes that they do not completely verify new block's information [3][4][5].. so with this suggested feature, we know there will be another layer of PoW that makes them more money if they verify new blocks with more accuracy.. at least people could could stop doubting them..


I think I have a solution. first of all, the shadow-coin relies on the same merkle-root-hash of the main coin and this makes fake/semi-fake nodes useless. so, by a simple change in block version and add rows like shadow-address, shadow-nBits and shadow-nonce to the header, we could merge shadow-coin to the main network.. but handling this needs a trick. the shadow-coin in block header could refer to 10 blocks (or more) back in the chain (somehow passes enough block confirmation for the main coin) and aim at preventing unwanted delays in new block generation, some blocks could contain two or more rows of shadow-coins while some blocks contain no shadow-coin.

and there is also a raw idea here and I ask for evaluating it please: "while generation of shadow-coin takes place by contribution of all full nodes, with some proper changes in codes, reorg process by the main coin could get banned after broadcasting a block with shadow-coin in its header.. so I could see some good effects on disappointing selfish-miners and making it really harder to perform a 51% attacks.."

this also could answer pro Anti-ASIC bitcoiners [6] that abide by decentralized soul of cryptocurrencies..

References:
[1] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
[2] https://www.zdnet.com/article/researcher-kept-a-major-bitcoin-bug-secret-for-two-years-to-prevent-attacks/
[3] https://medium.com/nervosnetwork/dont-trust-verify-7c866ad1ed5b
[4] https://bitcoin.stackexchange.com/questions/80808/does-a-transaction-always-get-verified-processed-by-all-full-nodes-in-the-networ
[5] https://bitcoin.stackexchange.com/questions/81872/how-many-nodes-need-to-validate-a-newly-created-block
[6] https://bitcointalksearch.org/topic/ethereum-anti-asic-fork-is-it-the-right-time-for-bitcoin-too-5095048

Could you explain what is the point of making it harder for people to run a node?
If it is security then you'll have to first explain what the security flaw and the attack vector is that you are trying to prevent and then explain whether this step would prevent it or not.
You should also explain why wouldn't this make running a full node harder than it is and what would you do to avoid discouraging people running full nodes.

Technically in a decentralized peer to peer network there shouldn't be a server client relationship, everyone is a peer (at the same level).

You aren't changing anything about the communication, just adding a computation step in handshake.
Again please explain what "lack of safety" you are trying to solve.

What would stop someone from running a farm of fake or semi-fake nodes with minimal cost earning that "shadow reward"? You certainly won't be able to increase the difficulty of this PoW without making it impossible for regular users to run a full node.

Hi there..

due to coding our CORE in Azim Block Chain project [1], we did find out there could be an opportunity to set a tiny version of PoW during handshaking stage among nodes. In this workflow, server nodes send a challenge like job to client nodes and ask for solving a difficulty thingy. With this method:

1- We may meet a safer communication among nodes.
2- We could issue a shadow-coin under the main coin that encourages people to install more and more perfect nodes with same incentives that main PoW does to the entire network.

In Bitcoin, while we have sha256 algorithm in main coin, RandomX could be a good candidate for the shadow-coin as second layer of PoW..

any feedback welcome..


References:
[1] https://bitcointalksearch.org/topic/the-necessity-of-flash-back-pinning-in-structure-of-transactions-5089384