<p>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:</p>

<blockquote>
  <p>because of significant latency of proof-of-work for transactions confirmation, this consensus mechanism is vulnerable against doublespending</p>
</blockquote>

<p>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</p>

<blockquote>
  <p>... This does not seem to be a fair and democratic process. </p>
</blockquote>

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

<blockquote>
  <p>Because of latency in block generation and transactions confirmation, the scalability is
  another problem of proof-of-work</p>
</blockquote>

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

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

<blockquote>
  <p>Do you think it is practicable to detect MAC address change in a network like Bitcoin network?</p>
</blockquote>

<p>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</p>

CC BY-SA 4.0
2018-11-10T16:03:33.807Z
Thank you, but how about possibility of detecting MAC address change in Bitcoin-like network by Cisco Port Security? Thanks
Questioner
CC BY-SA 4.0
2018-11-10T16:11:14.290Z
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]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.395.7485&rep=rep1&type=pdf And [4]: https://www.eecis.udel.edu/~ruizhang/CISC859/S17/Paper/p9.pdf
Questioner
CC BY-SA 4.0
2018-11-10T16:20:20.707Z
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: https://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
CC BY-SA 4.0
2018-11-10T16:26:57.460Z
Also, you can see the Table 1. Comparison of permissioned consensus approaches and standard PoW in the same reference: https://bit.ly/2vZfz0q
Questioner
CC BY-SA 4.0
2018-11-10T16:37:13.680Z
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
CC BY-SA 4.0
2018-11-10T17:19:42.327Z
I think you should first learn basics before trying to design consensus alg. Sorry, your paper is nonsense. That includes the idea with MACs which are not presented to nodes on the other side of the planet and thus obviously unverifiable.
Wapac
CC BY-SA 4.0
2018-11-10T17:25:48.457Z
Are you sure it's me who proposed this idea?! Instead of imagination, it's better to answer technically the question!
Questioner
CC BY-SA 4.0
2018-11-10T17:34:23.217Z
I showed just a few of flaws in your paper. It is likely yours as you present the same level of misunderstanding as the author and you seem to be angry about the criticism. It is a safe bet. Sorry if I am wrong and you are not the author. Then just ignore that part and everything else still holds.
Wapac
CC BY-SA 4.0
2018-11-10T17:38:26.960Z
No why should I be angry?! even If I had proposed this idea !! When I ask a question on an idea, I am the first person who started criticism on that idea obviously !!
Questioner
CC BY-SA 4.0
2018-11-10T17:44:24.770Z
but you didn't answer the main question: possibility of detecting MAC address change in Bitcoin network using Cisco Port Security, the rest of paper is not the question ...
Questioner
CC BY-SA 4.0
2018-11-10T17:56:47.047Z
added answer for that
Wapac
CC BY-SA 4.0
2018-11-10T18:05:31.053Z
However, according to Cisco document (https://bit.ly/2zJclAv), (search "MAC address change detection globally enabled") it could be enabled such that a MAC address change would be detectable.
Questioner
CC BY-SA 4.0
2018-11-10T18:22:31.107Z
and why you think "globally" has such a meaning in that context as you think it has? it has not. MAC is not send over TCP/IP. it is not visible to other computerson the Internet. in other words - please tell me MAC address of stackexchange.com server...
Wapac
CC BY-SA 4.0
2018-11-10T18:27:27.123Z
so, what does globally mean there? And what does "MAC address change detection" mean in Cisco doc?
Questioner
CC BY-SA 4.0
2018-11-10T18:41:39.053Z
concerning MAC address of stackexchange.com server: I think the situation is different, because I am not connected to stackexchange.com network.
Questioner
CC BY-SA 4.0
2018-11-10T19:07:25.900Z
exactly, that's why it is not usable outside of its network. so you answered yourself. and even if you were, you can't just trust a number that can be self assigned
Wapac
CC BY-SA 4.0
2018-11-10T19:10:32.603Z
so, I don't understand what is the **use case** of detecting MAC address change by Cisco Port Security? Meanwhile, in that case, a node is connected to ex. Bitcoin network but I am not connected to stackexchange.com network.
Questioner
CC BY-SA 4.0
2018-11-11T05:11:29.017Z
@sas Or, to put it even more simply, say you see 18,000 different addresses on a port. Is that because there's 18,000 people connected? Or is that because there's one person connected who is faking all the addresses? Are humans supposed to investigate every port on every network and somehow all agree on who gets a vote and who is a fake? BY WHAT METHOD WOULD THEY COME TO THAT AGREEMENT? Some kind of consensus algorithm? Who would get a vote in that agreement to decide who gets a vote on transactions?
David Schwartz
CC BY-SA 4.0
2018-11-11T09:36:14.183Z
@David Schwartz when you say "The paper is completely idiotic" you mean even parts of PoW criticism and counting its problems?
Questioner
CC BY-SA 4.0
2018-11-11T19:24:11.220Z
@sas No, sorry. Just this part of it. I make that clearer in my answer. (I wonder if someone who didn't understand the issue added that part. The rest of the paper isn't so obviously wrong.)
David Schwartz
CC BY-SA 4.0
2018-11-10T15:52:43.513Z
2018-11-10T17:56:30.370Z
2018-11-10T17:56:30.370Z
Wapac
<p>While I make no comments about the rest of the paper, that part of the paper is complete nonsense. Here's the excerpt:</p>

<blockquote>
  <p>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.</p>
</blockquote>

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

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

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

<p>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?</p>

<p>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?</p>

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

<p>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?</p>

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

<p>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?</p>

<p>We have two choices:</p>

<ol>
<li><p>All nodes treat all MAC addresses as valid all the time.</p></li>
<li><p>Nodes treat some MAC addresses as invalid.</p></li>
</ol>

<p>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?</p>

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

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

CC BY-SA 4.0
2018-11-11T09:25:32.503Z
_"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
CC BY-SA 4.0
2018-11-11T09:27:47.203Z
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
CC BY-SA 4.0
2018-11-11T09:32:14.233Z
Do you think non of approaches to detect MAC address spoofing does not work? https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=mac+address+spoofing+detection&btnG=
Questioner
CC BY-SA 4.0
2018-11-11T19:33:10.990Z
@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
CC BY-SA 4.0
2018-11-11T19:39:57.597Z
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
CC BY-SA 4.0
2018-11-11T20:00:50.750Z
@Pieter Wuille, Yes I think the problem is **decentralized** MAC spoofing
Questioner
CC BY-SA 4.0
2018-11-11T20:02:46.220Z
@Pieter Wuille, 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
CC BY-SA 4.0
2018-11-11T20:12:12.113Z
I don't see how that can prevent DoS attacks, but it seems like a topic for another question.
Pieter Wuille
CC BY-SA 4.0
2018-11-11T20:28:02.647Z
@Pieter Wuille , In fact, that  section i.e. Definition 1.1 (Node) that is related to definition of a node by concatenating MAC+public key will be changed.
Questioner
CC BY-SA 4.0
2018-11-11T05:19:03.153Z
2018-11-11T19:44:07.763Z
2018-11-11T19:44:07.763Z
David Schwartz
<p>The paper that has been published here: <a href="https://dl.acm.org/citation.cfm?id=3282283" rel="nofollow noreferrer">https://dl.acm.org/citation.cfm?id=3282283</a> proposes a consensus algorithm based on distributed voting process in which it claims that it would be possible to <strong>detect (and not prevent)</strong> MAC address change using <strong>Cisco Port Security</strong> in a crypto-currency network like <strong>Bitcoin</strong> network, because this proposed idea is based on <strong>one-machine-one-vote</strong> and so it is important to <strong>detect</strong> MAC address change in a <strong>Bitcoin-like</strong> network.</p>

<p>Do you think it is practicable to <strong>detect</strong> MAC address change in a network like <strong>Bitcoin network</strong>? </p>

<p>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, <strong>if Bitcoin network uses Cisco Port Security configuration for detecting MAC address change?</strong> Thank you</p>

<p>P.S. MAC address change detection using Cisco Port Security is described here: <a href="https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4000/8-2glx/configuration/guide/sec_port.pdf" rel="nofollow noreferrer">https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4000/8-2glx/configuration/guide/sec_port.pdf</a> and here: <a href="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" rel="nofollow noreferrer">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</a></p>

CC BY-SA 4.0
2018-11-10T21:27:29.673Z
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
CC BY-SA 4.0
2018-11-10T22:07:59.713Z
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
CC BY-SA 4.0
2018-11-11T19:36:16.227Z
@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
CC BY-SA 4.0
2018-11-11T19:55:39.123Z
@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
CC BY-SA 4.0
2018-11-12T01:10:05.110Z
@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
CC BY-SA 4.0
2018-11-12T10:33:38.627Z
@David Schwartz , In fact, it had been considered in the paper, provided that we can detect MAC address spoofing (Definition1.1.Node) such that system can control the maximum authorized number of transactions per day via a node, meaning that in case of increasing the rate of incoming transactions, the network decreases the maximum authorized number of transactions via a node and vice versa. But, in case of **impossibility of detecting MAC spoofing** another alternative must be considered either by(1)keeping tx fee-free and adding another **external** cost like Po-SpaceTime or (2) adding fees.
Questioner
CC BY-SA 4.0
2018-11-14T00:04:13.107Z
@sas In other words, it cannot deliver fee free transactions. And detecting MAC spoofing is not the problem -- even if we could detect MAC spoofing, we still couldn't use MAC spoofing detection because coming to a consensus on whether a MAC is spoofed (in the face of an arbitrarily large number of malicious adversaries) is the problem, not detecting the spoofing. The paper (at least this part) fundamentally misunderstands the problem it's trying to solve.
David Schwartz
<network>
Possibility of detecting MAC address spoofing in Bitcoin network?
Questioner
# Possibility of detecting MAC address spoofing in Bitcoin network?

(Asked by: username_0 on 2018-11-10)

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>

**Tags:** network

> **Comments:**
> **username_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?  
> **username_0**: 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.  
> **username_2**: @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.)  
> **username_0**: @username_2, 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  
> **username_2**: @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.  
> **username_0**: @username_2 , In fact, it had been considered in the paper, provided that we can detect MAC address spoofing (Definition1.1.Node) such that system can control the maximum authorized number of transactions per day via a node, meaning that in case of increasing the rate of incoming transactions, the network decreases the maximum authorized number of transactions via a node and vice versa. But, in case of **impossibility of detecting MAC spoofing** another alternative must be considered either by(1)keeping tx fee-free and adding another **external** cost like Po-SpaceTime or (2) adding fees.  
> **username_2**: @sas In other words, it cannot deliver fee free transactions. And detecting MAC spoofing is not the problem -- even if we could detect MAC spoofing, we still couldn't use MAC spoofing detection because coming to a consensus on whether a MAC is spoofed (in the face of an arbitrarily large number of malicious adversaries) is the problem, not detecting the spoofing. The paper (at least this part) fundamentally misunderstands the problem it's trying to solve.  

---

## 2 answers

### Answer by username_3 on 2018-11-10. Score: 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

> **Comments:**
> **username_0**: Thank you, but how about possibility of detecting MAC address change in Bitcoin-like network by Cisco Port Security? Thanks  
> **username_0**: 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]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.395.7485&rep=rep1&type=pdf And [4]: https://www.eecis.udel.edu/~ruizhang/CISC859/S17/Paper/p9.pdf  
> **username_0**: 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: https://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."_)  
> **username_0**: Also, you can see the Table 1. Comparison of permissioned consensus approaches and standard PoW in the same reference: https://bit.ly/2vZfz0q  
> **username_0**: 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.  
> **username_3**: I think you should first learn basics before trying to design consensus alg. Sorry, your paper is nonsense. That includes the idea with MACs which are not presented to nodes on the other side of the planet and thus obviously unverifiable.  
> **username_0**: Are you sure it's me who proposed this idea?! Instead of imagination, it's better to answer technically the question!  
> **username_3**: I showed just a few of flaws in your paper. It is likely yours as you present the same level of misunderstanding as the author and you seem to be angry about the criticism. It is a safe bet. Sorry if I am wrong and you are not the author. Then just ignore that part and everything else still holds.  
> **username_0**: No why should I be angry?! even If I had proposed this idea !! When I ask a question on an idea, I am the first person who started criticism on that idea obviously !!  
> **username_0**: but you didn't answer the main question: possibility of detecting MAC address change in Bitcoin network using Cisco Port Security, the rest of paper is not the question ...  
> **username_3**: added answer for that  
> **username_0**: However, according to Cisco document (https://bit.ly/2zJclAv), (search "MAC address change detection globally enabled") it could be enabled such that a MAC address change would be detectable.  
> **username_3**: and why you think "globally" has such a meaning in that context as you think it has? it has not. MAC is not send over TCP/IP. it is not visible to other computerson the Internet. in other words - please tell me MAC address of stackexchange.com server...  
> **username_0**: so, what does globally mean there? And what does "MAC address change detection" mean in Cisco doc?  
> **username_0**: concerning MAC address of stackexchange.com server: I think the situation is different, because I am not connected to stackexchange.com network.  
> **username_3**: exactly, that's why it is not usable outside of its network. so you answered yourself. and even if you were, you can't just trust a number that can be self assigned  
> **username_0**: so, I don't understand what is the **use case** of detecting MAC address change by Cisco Port Security? Meanwhile, in that case, a node is connected to ex. Bitcoin network but I am not connected to stackexchange.com network.  
> **username_2**: @sas Or, to put it even more simply, say you see 18,000 different addresses on a port. Is that because there's 18,000 people connected? Or is that because there's one person connected who is faking all the addresses? Are humans supposed to investigate every port on every network and somehow all agree on who gets a vote and who is a fake? BY WHAT METHOD WOULD THEY COME TO THAT AGREEMENT? Some kind of consensus algorithm? Who would get a vote in that agreement to decide who gets a vote on transactions?  
> **username_0**: @username_2 when you say "The paper is completely idiotic" you mean even parts of PoW criticism and counting its problems?  
> **username_2**: @sas No, sorry. Just this part of it. I make that clearer in my answer. (I wonder if someone who didn't understand the issue added that part. The rest of the paper isn't so obviously wrong.)  

---

### Answer by username_2 on 2018-11-11. Score: 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.

> **Comments:**
> **username_0**: _"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.  
> **username_0**: 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.  
> **username_0**: Do you think non of approaches to detect MAC address spoofing does not work? https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=mac+address+spoofing+detection&btnG=  
> **username_2**: @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.)  
> **username_4**: 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.  
> **username_0**: @username_4, Yes I think the problem is **decentralized** MAC spoofing  
> **username_0**: @username_4, 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  
> **username_4**: I don't see how that can prevent DoS attacks, but it seems like a topic for another question.  
> **username_0**: @username_4 , In fact, that  section i.e. Definition 1.1 (Node) that is related to definition of a node by concatenating MAC+public key will be changed.  

---

