Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive
for people to run full nodes and design a system for people to setup
full nodes in an acceptable timeframe
Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today,
some miners became crazy, the situation would be much more different
if more full nodes were there
Because, how comes everybody perfectly knows the plans of the
conspiring miners? They were stupid enough to explain very precisely
how they will perform the attack?
If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for
the new sw), not difficult, not so expensive
Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange
transactions) and reject them, but this further depends on the
ability of current full nodes to upgrade, which apparently is not
what they do the best
I don't know what "Time is running short I fear" stands for and when
50% is supposed to be reached
Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based
on a new proof of something does not look to be ready, then maybe
the btc folks should ask Bram Cohen (who by some luck is
participating to this list) to resurrect the bitcoin miner Epic
Scale which Bittorrent Inc (in an umpteenth dubious attempt to make
money) tried some time ago to include quietly in utorrent forgetting
to ask the authorization of the selected users, then utorrent users
might upgrade (potentially 150 M), and the resulting mining power
might be sufficient, depending on the incentive for this, which is
TBD
Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when
you think you have closed it, run things you don't know, etc, so
quite efficient in this situation
Then if btc folks wants to promote full nodes too, it would not be a
bad idea to put the bitcoin-qt blockchain + chain state in a torrent
making sure it is seeded correctly (there are plenty of academics
here, they can do it and run full nodes too) so people can download
it and setup full nodes (incentive TBD too) assuming they know about
upnp/port forwarding
Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :
When the original white paper was written
the idea was that nodes
would be miners at same time. That the distribution of mining
power
being mostly on par with the distribution of nodes if I understand
correctly. The problem we face now I fear, is the mining power
becoming centralized. Even if every bitcoin node invested a $1000
into mining power and mined at a loss, it still would not even
make a dent in hash distribution. Currently there are around 6000
known nodes. If each node invested $1000 for say 10 ths of hashing
power. At current hashrate of around 3,674,473,142 GH/s this would
only make up %16 of hash power. This is out of balance as while
nodes are distributed mining power is becoming very centralized
due to the creation of monopolization of ASICs. The problem we
are facing is a small group of a couple people whom control a
large amount and growing of hash power. At time of this writing
it has quickly risen to 39% and at current rate will soon become
50% of hashing power that is controlled by a small group of a few
people. Their intentions are too hijack the bitcoin network to a
cryptocurrency that suits their dangerous agenda. Dangerous
because
their plan would centralize power of consensus as I understand it,
to themselves the miners. Dangerous also because the code base of
the attempting subverters is buggy, insecure, and reckless from a
technological standpoint. Even though they only have very minute
amount of nodes compared to legitimate bitcion nodes, the danger
is that they are very quickly taking over in mining power. While
it is true that nodes will not accept invalid blocks that would be
attempted to be pushed by the conspirators, they are threatening
to
attack the valid (or in their words, "minority chain") by
dedicating
some mining power soley to attacking the valid chain by mining
empty
blocks and orphaning the valid chain. So even though the majority
of nodes would be enforcing what blocks are valid and as a result
block the non-compliant longer chain, the conspiring miner can
simply
(as they are currently threatening to) make the valid chain
unuseable
by mining empty blocks.
If a malicious miner with half or majority control passes invalid
blocks, the worst case scenario is a hardfork coin split in which
the non-compliant chain becomes an alt. However the problem is
that
this malicious miner is very recently threatening to not just
simply
fork, but to kill the valid chain to force economic activity to
the
adversary controlled chain. If we can simply defend against
attacks
to the valid chain, we can prevent the valid chain from dying.
While empty or near empty blocks would generally be protected by
the incentive of miners to make money. The threat is there if the
malicious miner with majority control is willing to lose out on
these transaction fees and block reward if their intention is to
suppress it to force the majority onto their chain.
Proposal for potential solution Update nodes to ignore empty
blocks,
so this way mined empty blocks cannot be used to DOS attack the
blockchain. But what about defense from say, blocks that are
not empty but intentionally only have a couple transactions
in it? Possible to have nodes not only ignore empty blocks,
but also blocks that are abnormally small compared to number of
valid transactions in mempool?
For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example.
What would be any potentials risks
and attacks resulting from both having such new rulesets and not
doing anything?
Lets assume that the first problem of blocking empty or near empty
blocks has been mitigated with the above proposed solution. How
likely and possible would it be for a malicious miner with lots of
mining power to orphan the chain after so many blocks even with
non empty blocks? Is there a need to mitigate this?
If so is it possible?
Time is running short I fear. There needs to be discussion on
various
attacks and how they can be guarded against along with various
other contingency plans.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist:
http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms