-2

The paper that has been published here: https://dl.acm.org/citation.cfm?id=3282283 proposes a consensus algorithm based on distributed voting process in which it claims that it would be possible to detect (and not prevent) MAC address change using Cisco Port Security in a crypto-currency network like Bitcoin network, because this proposed idea is based on one-machine-one-vote and so it is important to detect MAC address change in a Bitcoin-like network.

Do you think it is practicable to detect MAC address change in a network like Bitcoin network?

I mean assume a node is connected to a network like the Bitcoin network (en.bitcoin.it/wiki/Network), then if this node changes its MAC address, is it possible to notify the rest of Bitcoin network, if Bitcoin network uses Cisco Port Security configuration for detecting MAC address change? Thank you

P.S. MAC address change detection using Cisco Port Security is described here: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4000/8-2glx/configuration/guide/sec_port.pdf and here: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_nx-os-cfg/sec_portsec.pdf

  • 1
    Seems like this would just increase the attack surface of a PoS system to include all things MAC-spoofing related. And I think privacy concerns would be huge: who wants to tie their device to a history of usage on a cryptocurrency network? – chytrik Nov 10 '18 at 21:27
  • But as you said, MAC address is changeable and so the machine is not tied to transactions, but also the MAC address + public key is tied to transactions, the purpose is to force any user to use a separate machine for every vote for a transaction, meaning that as soon as user changes their MAC address, their machine has to be connected to the network as a new node and so a new registration. – Questioner Nov 10 '18 at 22:07
  • @sas If the issue is whether the MAC address adds any additional security, then the requirement for a new registration is irrelevant. You can trivially limit people to one vote per registration without using MAC addresses. But in fact, the MAC address usage just makes things worse as it makes the consensus algorithm vulnerable to failure if nodes disagree on which MAC addresses are valid. (Unless we just treat all MAC addresses as valid always.) – David Schwartz Nov 11 '18 at 19:36
  • @David Schwartz, And what do you think about the solution in case of removing MAC address from the node definition and keep the rest of paper? i.e. one-publicKey + one-registration = one vote. With other new ideas ex. using Confirmation Time Reward (CTR) instead of monetary reward (Definition 1.3) enabling supporting fee-free transactions, Priority Point table and Preventing Double-Spending (Definition 1.2 & Section 2.3), Avoiding broadcasting new state of blockchain and Preventing Blockchain Fork and Block-withholding (Section 2.4) and Immutability of Transactions (Section 2.6) Thanks – Questioner Nov 11 '18 at 19:55
  • @sas That would require me to review the entire paper, which I haven't had a chance to do. But it seems like they're trying to get something for nothing, which is not really possible. Every transaction imposes costs on every user of the system (storage, transfer, validation, etcetera) , so you have to impose costs on txn issuers somehow or the system will get clogged with junk. That's fundamental. If it's too cheap for bad guys to create txns, they'll overwhelm the good guys with junk. You need some rationing somehow. – David Schwartz Nov 12 '18 at 1:10
4

No, the paper is based on wrong assumptions and complete misunderstanding of bitcoin and the Internet. There are too many flaws to even list them in the paper. Here are just some of the claims that are wrong:

because of significant latency of proof-of-work for transactions confirmation, this consensus mechanism is vulnerable against doublespending

Double spending is the actual problem that bitcoin solved And the latency does not matter, there are many other coins that reduced the latency and they still need a mechanism to prevent double spending

... This does not seem to be a fair and democratic process.

This is completely wrong way of thinking, which in having something like democratic process to decide what is the correct ledger. It is like saying that the circumference of the circle should be decided by the majority instead of maths laws.

Because of latency in block generation and transactions confirmation, the scalability is another problem of proof-of-work

The proposed solution a slightly crippled proof of stake, but there are many coins that already use proof of stake that cannot be fooled as simply as the one proposed in the paper and they also have scalability problem because that is nature of the blockchain and not of the consensus algorithm.

It is pointless to continue and one can simply reject this idea due to too many flaws in the paper.

Do you think it is practicable to detect MAC address change in a network like Bitcoin network?

no. MAC address is trivial to fake/generate and most importantly, it is not visible to other nodes outside the local network segment. thus cannot be proven or used for consensus

  • Thank you, but how about possibility of detecting MAC address change in Bitcoin-like network by Cisco Port Security? Thanks – Questioner Nov 10 '18 at 16:03
  • And concerning effect of latency in double-spending: in paper is mentioned that "A considerable latency in inter-block time increases possibility of double-spending attack" Also "When a temporary fork occurs, it is possible for an attacker to make a double-spending attack" citations: [3]: citeseerx.ist.psu.edu/viewdoc/… And [4]: eecis.udel.edu/~ruizhang/CISC859/S17/Paper/p9.pdf – Questioner Nov 10 '18 at 16:11
  • Also, when you say "they also have scalability problem because that is nature of the blockchain and not of the consensus algorithm" Do you mean ex. PoW that is a lottery-based consensus has the same scalability of PBFT that needs n(n-1) message exchanges for n nodes ? Reference: bit.ly/2vZfz0q (see section: "Comparison of Consensus Types" where it is mentioned "The lottery-based algorithms are advantageous in that they can scale to a large number of nodes since the winner of the lottery proposes a block and transmits it to the rest of the network for validation.") – Questioner Nov 10 '18 at 16:20
  • Also, you can see the Table 1. Comparison of permissioned consensus approaches and standard PoW in the same reference: bit.ly/2vZfz0q – Questioner Nov 10 '18 at 16:26
  • And also when you say " proposed solution a slightly crippled proof of stake" as I know PoS is a lottery-based algorithm (similar to PoW) in which there is no message exchange and distributed voting, this paper is based on distributed voting. Meanwhile, as in abstract is mentioned, it's based on a one-machine-one-vote that makes it completely different with PoS. – Questioner Nov 10 '18 at 16:37
2

While I make no comments about the rest of the paper, that part of the paper is complete nonsense. Here's the excerpt:

It is possible to recognise a host in the network which has changed its MAC address. For example, Cisco Port-Security allows to prevent hosts from changing MAC address on a port. So, we can control the spam transactions with supporting fee-free transactions at the same time.

This is wrong for many reasons. The simplest one is this -- port security allows the person who operates a particular network device to tell if any of its ports are now being used by a device with a different MAC address. This is useless in a bitcoin-like network for a very obvious reason: MAC addresses are purely local to a single network.

Say I change my MAC address from A to B. This is only detectable on my local network. It cannot be detected outside of that network. So unless whoever operates my local network is trusted by the consensus scheme to specify what MAC addresses I may or may not use, the information that my MAC address changed is useless. Only one network operator has that information, and nobody has any particular reason to trust them if they try to report that information.

There is no decentralized way to authenticate MAC addresses or of preventing them from being changed, so a MAC address can never be trusted by a decentralized algorithm.

Say I operate the connection between two networks, A and B. Or even say I don't operate such a connection. There is no decentalized way to tell that I don't operate such a connection between networks. Maybe network B is real. Maybe it's fake. But if I tell network A (or anyone else in the world) that network B has 17,000 different MAC addresses, how can a decentralized system know that I'm lying?

Proof of work can be used to establish a consensus because there is no way two honest nodes can disagree over what is valid proof of work and what isn't. Proof of work serves as an indisputable arbiter of truth for all honest nodes in the network. But there is no way for all honest nodes in a network to agree whether a particular MAC addresses is legitimately owned by someone claiming it. So there is simply no way a MAC address can play any role in a consensus algorithm without some other consensus algorithm to get people to agree on which MAC addresses are validly owned and who they're owned by. What happens if nodes disagree on whether someone is entitled to claim a MAC address or not entitled to? How will they stay in consensus?

The problem of agreeing on whether a MAC is legitimate or spoofed (in the face of a large number of hostile adversaries) is no easier than agreeing which transactions are valid in a similar environment. So any method of agreeing on which transactions are valid that requires us to already agree on which MACs are valid would be utterly useless.

By contrast, if someone claims to have mined a particular block in a system using proof of work, we are automatically guaranteed that we will have universal agreement that the block is valid. If someone does not do the appropriate proof of work, we are automatically guaranteed that we will have universal agreement that the block is invalid. I can easily ensure my node honors all valid blocks and dishonors all invalid blocks, even in the fact of an arbitrary number of hostile adversaries who all lie to me. How can we do that with MAC address validity?

It's surprising how commonly I see algorithms that claim to be able to replace proof of work that begin by assuming we can do things that are in fact precisely the things that proof of work enable us to do.

How do we ensure that all honest participants will agree on which MACs are valid and which are not, even if the network has lots of dishonest participants? And if honest participants can't agree on whether a MAC is valid or not (and there is no known way for them to do this) then what purpose does the MAC address serve?

We have two choices:

  1. All nodes treat all MAC addresses as valid all the time.

  2. Nodes treat some MAC addresses as invalid.

If we choose option one, the MAC address adds no security at all. If we choose option 2, we risk breaking the consensus algorithm as nodes disagree on which MAC addresses are valid and which aren't and so disagree on which registrations are allowed to vote and which aren't. We would need some protocol to ensure universal agreement by the mutually distrustful participants on which MAC addresses are valid, which we do not have. And if we had such a protocol, why not just use it to agree on which transactions are valid?

Suppose you're a node and someone just introduced a registration with particular MAC address. What process should every node in the network go through to determine whether that MAC address should be allowed or not such that they will all get the same answer, will not shut out legitimate users, and will detect spoofing? How can anyone on the outside tell whether I have one or a hundred machines behind my home router? And we're relying on every participant being able to do so and somehow getting the same answer. It's utterly, comically ridiculous.

I have not reviewed anything else in the paper, but I did skim it and nothing seemed as obviously wrong as this part. I have to wonder if this part of the paper was written by someone who didn't understand the problem the paper is trying to solve.

  • "What happens if nodes disagree on whether someone is entitled to claim a MAC address or not entitled to?" According to the algo, a node includes MAC+public key and so all nodes' votes are counted and accepted. Assumption was to recognize MAC spoofing to ignore spoofed MACs, but it is not practicable to recognize, all votes are counted, however we need to keep in mind that for every registered node, user has to pledge a part of their coins, ex. if required coins for pledging for every node is c, for n nodes, they have to pledge nxc coins that in case of failure, they lose all nxc coin. – Questioner Nov 11 '18 at 9:25
  • Also, we can yet support fee-free tx, since there is no monetary rewards, instead there a Confirmation Time Reward (CTM) that of course is exchangeable with coins. – Questioner Nov 11 '18 at 9:27
  • 1
    @sas "Do you think non of approaches to detect MAC address spoofing does not work?" Nope. None of them work. Because the problem is NOT detecting MAC spoofing -- that's the fundamental misunderstanding. The problem is getting a large network which may contain mostly hostiles and with mutual mistrust to somehow agree which MACs are spoofed. The reason proof of work works is because all honest people will always agree whether a particular proof of work is valid regardless of how many hostiles say otherwise. (I added more details to my answer.) – David Schwartz Nov 11 '18 at 19:33
  • 1
    In addition, the mere concept of a "spoofed" MAC implies there exists an authority who can give out non-spoofed MAC addresses. Even if what you were trying was somehow possible, you've now turned that authority into the central trusted party in the network. – Pieter Wuille Nov 11 '18 at 19:39
  • 1
    I don't see how that can prevent DoS attacks, but it seems like a topic for another question. – Pieter Wuille Nov 11 '18 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.