A developer named Mark Friedenbach will present a paper in which he proposes a way to make a modification to the consensus mechanism of the network or to the size of the blocks without making a hardfork, taking advantage of the own operation of the protocol and a potential failure already known. However, his work has been questioned by other members of the technical community because it publicly reveals what appears to be an attack vector in the Bitcoin network that could lead to vulnerability.
According to Friedenbach, its intention is not to violate the network but to take advantage of the protocol's own operation , the block size limit and its timestamps, so that certain modifications of the network can be made without a strong bifurcation. However, the findings and the way to apply their proposal could be exploited by a malicious actor and compromise the welfare of the blockchain , according to Twitter user, Shinobi, and Bitcoin Core developer, Pieter Wuille .
The developer tried to settle the controversy through his Twitter account, ensuring that he is only explaining "how a change in PoW and / or an increase in block size could be done in a way that is perfectly compatible with previous versions". Their work, called Blocks of advancement: increases the capacity of the chain / settlement without Hard-Fork will be presented at the Scaling Bitcoin event, to be held in Tokyo in October.
The controversy with other developers started because of the sensitivity of the subject and the reluctance of Friedenbach in the handling of this information. The possibility of taking advantage of the increase in the size of the blocks to add information to the nodes -either to apply a change or an update- and "overload" the non-updated nodes, is an attack vector, according to Shinobi.
"It will increase the data load of the non-updated nodes. This is an attack vector, whatever the mechanism, "he wrote. Altering in an artificial or momentary way the operation of the protocol, even taking advantage of an already known error, should not be taken as any element in the opinion of the researcher.
While Friedenbach insisted that this is not an attack vector but a way to apply modifications to the protocol, Pieter Wuille also replied to this:
If that happens without a hardfork (and therefore opting for an increase in bandwidth by the node operator), how is it not an attack? (...) How do you make sure that this mechanism is not abused for more than that? If I understand correctly (but this is speculation), this means that miners can force additional bandwidth to unsuspecting nodes.
Pieter Wuille
Developer, Bitcoin Core
Friedenbach dismissed this idea, assuring that taking advantage of this vector and violating the network would imply a very high cost, emphasizing that this enormous expense would be in vain "since the block size limit would be restored" thanks to the proper functioning of the protocol. In addition, he added:
Bitcoin works on the theory of games with monetary incentives. I'm not sure how different it is to say that "the miners could attack 51% of the network even though it is expensive for them". The cost could go beyond the means of any actor, any increase would be restored very quickly.
Mark Friedenbach
Developer
Although it seems that it is a hard-to-execute attack vector, the Bitcoin Core developers' email list already has a thread for discussion. Thus, George Maxwell sent an e-mail entitled "Move to fix the time distortion attack", urging the members of the list to discuss the issue.
"There have not been too many other network consensus rules going on at this time, and I believe that at least several of the suggested proposals are fully compatible with the existing behavior and are only activated in the presence of exceptional circumstances, (an attack of temporary deformation) . So the risk of implementing these mitigations would be minimal, "he wrote in the mail.
In addition, he assured that although this type of vulnerabilities had been left aside to address more urgent or sensitive issues, it could be solved with a softfork.
