GIGAmeshLast Monday at 5:02 PM
any more discussions about securing the chain? increasing cost of attack etc?
something to deter/prevent an attacker spinning up a few thousand nodes and crippling the network?
YilunYesterday at 3:51 AM
@GIGAmesh Yes there are quite a few proposals. In addition to using work/stake as voting weight, a more secure one is being proposed recently that use VDF or other way to generate a random beacon, and then assign node id using a on Chain txn after node has joined the network. This would solve most concern people have been talking about. But really, the root cause that makes us easier to attack atm than bitcoin or ethereum is the token price, NOT the mechanism. Most permissionless blockchain are as easy/hard to attack as us from the network layer, but just the cost is proportional to token price. And actually we are harder to attack than most of them because we strictly restrict one node per IP. When we launch the mainnet stage and mining reward is boosted by 5x, the network count should grow naturally over 30k, making it much harder to attack, as we find it very hard to spin >5k nodes even on google cloud due to the lack of IP address. We actually tried recently to launch 5k nodes but only get 4.5k in the end. That’s why we consider 10k very important, because that means it’s much harder for someone to control 1/3 of the network easily. But even given the above facts, we still want to be more secure, that’s why we are proposing more ways to prevent Sybil attack.
GIGAmeshYesterday at 7:58 PM
@Yilun that all sounds interesting.
since VDF is not production ready it seems unlikely that will help pre mainnet release
im not sure that how long comparisons between classic blockchains and nkn hold
for example, bitcoin pools have huge pipes backed by cloudflare to keep them onmline
whereas in nkn pools do not exist. in addiiton to an attacker spinning up a few thousand nodes he could probably take a lot of good nkn nodes down to enhance the attack
nodes running in peoples homes using commercial routers can prob all be brought down in minutes with a simple DOS attack
pretty sure all commercial routers are crap and incapable of handling much “weird” traffic they are inundated with
bitcoin pooling, while centralized, does protect its partciipants
about price: seems a bit catch 22. security increases with nodecount which increases with price. but how does price increase without security?
amusing to imagine an attacker spinning up on gcloud. i doubt that would be choice
YilunToday at 1:33 AM
@GIGAmesh
It’s actually not about having pool or not, or how good the internet of miners are, it’s about almost every blockchain uses DHT as underlying topology and thus share some similar weakness. A very straightforward example: of everyone you know is bad guys, as long as they want to attack, they can make sure that you can never get good information, regardless of how powerful your node is. Actually, having a mining pool only makes it easier to attack, because mining pool aggregate multiple nodes into a single one, thus reducing the effective number of neighbors.
This is a common and known issue for permissionless blockchain, and currently there is no way to solve it completely because by definition, whoever put most resources in a public blockchain “own” it, so it’s not a problem at all by definition. If we could prevent someone from putting resources and mining, it could also be used to prevent you or anyone specifically from joining. All we can do is to raise the cost of joining, e.g. economic cost, time cost, etc.
From you question I think you probably haven’t realized how general this feature/bug of public blockchain is so you may find this link interesting: https://www.crypto51.app/ (this is for 51% attack, not the network attack I mentioned above since I cannot find chart like this, but 51% attack is a much much worse attack in PoW that allows double spending if no checkpoint is applied), and you should probably ask Bitcoin or Ethereum or every other top blockchain how they get through the initial insecure phase 
GIGAmeshToday at 2:06 AM
if NKN were attacked i imagine a botnet, not a bunch of “expensive” vps nodes https://en.wikipedia.org/wiki/Botnet#Historical_list_of_botnets
A botnet is a number of Internet-connected devices, each of which is running one or more bots. Botnets can be used to perform distributed denial-of-service attack (DDoS attack), steal data, send spam, and allows the attacker to access the device and its connection. The owner …
looking at the list of botnets in the above article the smallest start from around 10,000 machines
which means NKN target could be around 30k nodes
more generally @Yilun (and ty for ur time and detailed explanation) given NKN’s purpose (to relay traffic) simply stalling the network would be enough to discredit it
All the IoT devices communicating over NKN would be silenced and the network effectively shut down
since Bitcoin is about sending money, delays or stalling are not as bad on BTC as it would be on NKN, imo anyway
YilunToday at 2:12 AM
The attacker can use the same botnet to attack any other blockchain, and it’s much easier to attack them because: 1. they have much less nodes, which means that many malicious is enough to occupy say 90% of all nodes in the network and attack very easily. 2. lots of those bot have very low resources, which means they cannot join NKN network and starting consensus normally and being part of the network because we are a load-balanced relay network and everyone has to participate in relay and consensus. While for other PoW blockchain, there is not minimal resources to join the network and become a full node – you just don’t need to compute hash! So many of those nodes cannot used to attack NKN but can be used to attack Bitcoin from the network layer (not intuitive :))
GIGAmeshToday at 2:12 AM
there are botnets for hire and i shudder to think how affordable a 10k botnet is
as i said “since Bitcoinn is about sending money, delays or stalling are not as bad on BTC as it would be on NKN”
but maybe others do not agree
since im waiting 10 mins for a confirm whi cares about delays, whereas all the data NKN relays is mission critical and real-time
YilunToday at 2:14 AM
Oh I think you mix 2 things up: onchain txn and offchain data transmission. For the past time when our testnet stop producing blocks, the relay data never get stopped!
Actually the data transmission never stopped since the first launch of our testnet
GIGAmeshToday at 2:15 AM
ah yes, true
so there is no way an attacker can kill data traffic relay by killing nodes?
YilunToday at 2:15 AM
And the currently version takes latency into consideration and thus will not forward packets into nodes having bad network like the bot you mentioned
Even if he killed 95% of the nodes which we have tried, it will only have affect part of the traffic for a few seconds!
And as long as there are nodes in the network, traffic won’t be killed, but just the aggregated capacity depends on network size
GIGAmeshToday at 2:22 AM
thanks Yilun. Not for the first time i forget about the separation of data relay and mining
stop producing blocks, the relay data never get stopped!
this is interesting…
YilunToday at 2:23 AM
Haha that’s the beauty of layer 2!
GIGAmeshToday at 2:23 AM
but begs the question, if this happens who gets paid?
YilunToday at 2:23 AM
What happens you meant?
GIGAmeshToday at 2:23 AM
data is being sent (an paid for) but no blocks are being produced
YilunToday at 2:25 AM
Oh it’s like this: when data is being sent, sigchain is being accumulated for a period, and then block proposer (the one who get mining reward) is selected from the accumulated sigchain. When block is stopped, sigchain is still being accumulated to select the future block proposer, the only difference now is that it’s accumulated for a longer time, and everything else is the same(edited)
GIGAmeshToday at 2:29 AM
does the sigchain in anyway verify or authenticate the data being transmitted? e.g. does the sigchain prevent MITM attacks in NKN?
lets say i setup a bunch of NKN nodes only intended to MITM and change data packets received on the fly toomething malicious
does the sigchain protect the data integrity from sender to receiver i guess is what im asking
YilunToday at 2:32 AM
Yes it has very strict checks. The sigchain header contains data hash, and all signature depends on it. If you try to change the data, you have to re-sign all signatures in signature chain
GIGAmeshToday at 2:34 AM
ok IF an attacker stops block production and stalls the sigchain, the attacker has potentially the ability to MITM data sent over NKN?
YilunToday at 2:39 AM
Nope that’s totally separated. Actually data transmission is totally independent of block chain when it’s being transmitted except: 1. The sigchain header contains the latest block hash when sigchain is being generated 2. When a sigchain is completed (which happens after data has been delivered), it will be checked and may be broadcasted to the network as a candidate if it’s lucky enough. So whether the block production stops or not will not affect data transmission at all
GIGAmeshToday at 2:48 AM
So whether the block production stops or not will not affect data transmission at all . But it will affect the payment for the data transmission right?(edited)
YilunToday at 2:49 AM
Not really, it just delays it
GIGAmeshToday at 2:49 AM
it could be delayed for quite a time
presumabyt smart contracts would be most affected
the SC receives the data but no token to act upon it(edited)
YilunToday at 2:50 AM
The current type of traffic is free and thus not affected. We also have a session based payment, which is based on a simple state channel (layer 2). The whole point of layer 2 is delayed and aggregated payment because each single payment is so tiny
So it won’t be a problem at all
But you are right, onchain txn like transfer txn, smart contract will be affected mostly if block production stops(edited)
GIGAmeshToday at 2:59 AM
stopping block production cant be good even if people get their tokens eventually. Because of its design maybe NKN can withstand such a disaster better than most (data still gets relayed) but there are not many worse things for a crypto than that. The current type of traffic is free : yeah but NKN will need non-free traffic to support thousands of nodes (obv blcok rewards will become way too scarce tio support growth)(edited)
YilunToday at 3:00 AM
Yes you are right, but they will still be based on payment channel and thus delay is not a problem. But in general it’s true that stopping blocks is not a good thing of course
GIGAmeshToday at 3:01 AM
anyway you are (as ever) generous with both time and mind. ty Yilun. I will continue to think of ways to cripple NKN thanks buddy(edited)
YilunToday at 3:01 AM
(edited)
GIGAmeshToday at 3:02 AM
so to recap (im prob confused again)
1. The sigchain does not verify the authenticity of the data packets themselves. A MITM could change data packets on-the-fly without the sigchain knowing (edited)
YilunToday at 3:09 AM
You got the reverse! It DOES verify and MITM attack WILL BE detected! (edited)
1
And both changes to the data and changes to the path (adding, removing, changing a node) WILL BE detected because sigchain is a 2-way binded chain, stricter than blockchain itself (which is a 1-way chain)
GIGAmeshToday at 3:14 AM
if the attacker stops block production and stalls the sigchain is the MITM protection gone?(edited)
YilunToday at 3:16 AM
Whether block production stops does not affect this. Sigchain is MITM-resilience because of its data structure, and has nothing to do with block, blockchain or anything else(edited)
So in short, sigchain is ALWAYS MITM-resilience no matter what(edited)
GIGAmeshToday at 3:18 AM
so block production has literally zero impact on the integrity of data sent over NKN?
YilunToday at 3:19 AM
That’s true!
GIGAmeshToday at 3:23 AM
So NKN makes use of blockchain ONLY to incetivize running a node? And without the blockchain everything would be just fine, except no rewards?(edited)
YilunToday at 3:25 AM
Yes, to be more precious, except for delayed rewards
YilunToday at 3:34 AM
Or we can say this way: our core services including data transmission, and publish to subscribers, either do not rely on blockchain, or rely only on read data from blockchain (which no one can stop). This is because writing to (new) block is not scalable, so we avoid them from being the bottleneck from the design level
GIGAmeshToday at 3:35 AM
mimblewimble?
it’s not that i imagined the data itself being enshrined in the blockchain. obv the bloat is too much. but i had imagined that NKN made use of the blockchain to secure the data sent over the network. however (and confusingly in name) the sigchhain does this, and does it without the need for a blockchain.(edited)
YilunToday at 3:40 AM
Not mimblewimble, it’s more similar to layer 2
YilunToday at 3:53 AM
Blockchain itself is not scalable, everything goes to every node. You definitely don’t want to do it for every packet sent in the network! The “correct” and only way to do scalable data transmission is to have only limited relay nodes involved, like what we did in sigchain. We also use blockchain to make data transmission safer as we include latest block hash in sigchain. But on the other hand, we do use the data transmission part to empower one of the world’s most efficient and decentralized blockchain!
PS: some of the questions you asked are valuable to other people, so it would be good to post them in a publicly searchable place like the forum. If you don’t mind, you can ask questions there so other people can also see our discussions later.
GIGAmeshToday at 4:38 AM
@Yilun I like that the blockchain keeps a record of sigchains and “proves” the data was untampered with. But does the sigchain prove that ALL data sent across NKN is untampered with, or only the data that has gone into producing it? If NKN starts realying tonnes of data from different start/endpoints does the sigchain really prove ALL data was received as intended?
Im glad you feel these questions might be useful for some. Maybe ill try to boil it down and post my findings in the forum. thanks Lukas
YilunToday at 4:58 AM
@curry Each sigchain proves that some data (the ones it is associated with) is untempered with, and receiver (alos relay nodes) will be able to know and stop to sign the signature chain elements, and the receiver will of course discard the data. If any data is tempered with, that signature chain will be thus not qualified to be selected. Combined together, ALL data will be protected.
GIGAmeshToday at 5:06 AM
ok, so any attempts at tampering will be obvious to next node in the nkn circuit and the malicious packets will be discarded automatically, or still relayed to the destination and then discarded?
YilunToday at 5:09 AM
Both strategy are doable and should have the same security level. It depends on whether we want to minimize verification cost (if few attackers) or minimize invalid bandwidth usage (if more attackers).