Eliminating ACP
-
I asked Sunny to comment:
"Actually after v0.5 I think peercoin would operate in such a mode. Although it’s not that simple by the look. In peercoin paper I mentioned that we tried to design a distributed checkpointing, but the main issue with it is that there could be a network split attack on the mechanism.
So the reorganization depth limit is a fixed parameter, set to kinda deep such that a network split attack is much more costly than a typical double spending attack.
This could mean that double-spending protection would be weakened slightly, that you could see >6 depth double spending attack, but network would be decentralized. The reorg depth limit could be set to for example 500 blocks.
Best Regards,"
-
[quote name=“wrapper0feather” post=“52126” timestamp=“1389711177”]
“Loyal network”
[/quote]Go onnnn. What is this “loyal network” of which you speak?
-
[quote name=“Justabitoftime” post=“52138” timestamp=“1389715441”]
I asked Sunny to comment:"Actually after v0.5 I think peercoin would operate in such a mode. Although it’s not that simple by the look. In peercoin paper I mentioned that we tried to design a distributed checkpointing, but the main issue with it is that there could be a network split attack on the mechanism.
So the reorganization depth limit is a fixed parameter, set to kinda deep such that a network split attack is much more costly than a typical double spending attack.
This could mean that double-spending protection would be weakened slightly, that you could see >6 depth double spending attack, but network would be decentralized. The reorg depth limit could be set to for example 500 blocks.
Best Regards,"
[/quote]Thanks very much for doing that.
-
That’s great news. Thanks for the awesome response Sunny.
[quote name=“kris_davison” post=“52110” timestamp=“1389706572”]
SO are we saying that the only reason ACP works now is because there is only one version of the truth regarding a valid block.
If this needed to be arrived at by consensus which would be great we would need a way of dealing with a node in the 49% fork who is only connected to other 49% fork nodes and would essentially be disregarding any changes below 3 blocks ago which a re-org back into the 51% fork would require.
[/quote]Such net-splits are highly unlikely. Remember they don’t form conduits along which they blocks replicate, they form meshes in which the blocks are broadcast around.
In the case of a large regional outage, it’s conceivable that a pool starts mining a chain that gets followed locally, and the chain becomes long enough to hit a checkpoint (500 blocks as Sunny suggested), that region would be forever on the net-split chain. This is bad, but it’s not catastrophic. Either miners agree to voluntarily orphan the chain, or they stay forever on a separate chain which becomes it’s own currency.
I think that’s the right way forward, but I’d like to hear other opinions on the matter.
[quote]
How many nodes peers does each node actually need to connect to? maybe there is a way to essentially ask / find the answer from each known node to then reach a consensus rather than only using nodes that are directly connected?
[/quote]Exactly 1, the one with the longer chain. That’s all that matters, unless the chain is of length longer than the checkpoint height.
-
I don’t get this at all. Won’t you just have multiple forks all ignoring each other?
-
I think blockchain spliting and then an indexing meta level above the current currencies would evolve / is evolving.
Since they are an easy solution to the problems of blockchain bloat, currency mixing and multi currencies. Could adding that option now also resolve the ACP, “what is history” question?. For instance a “reputation meta layer”
Also, we have already pointed out a 20% attack is not insignificant. Bitcoin seem to be very much resting on their laurels in this respect, with a blind double think when talking down alternate currencies.
Instead of being 100% sure (As the central solution tries to be) or 0% if it is off, It just needs to be say 20% sure to direct the system truthfully in most cases.
or to put another way, if I 99% trust someone and they are 20% sure this is history is OK, 0% reason to think it is not OK
(i.e. from a trusted source). Then is very likely to be OK but with only 20% trust.If there could be a 51% consensus, on where 80% certain true history falls. That would prevent most attacks being viable.
i.e. the solution does not have to be perfect in a self aligning system, just enough to push the system in the required direction, it will self align automatically from there.
We have seen with attacks at Feathercoin, they stop as soon as it is not theoretically viable…
On the other hand, there is double think as well, in the argument against ACP.
One argument against ACP was that it was not in the Bitcoin the paper and that Alternate currencies that should die were kept alive by ACP.
This new p2p history assessment system would be even stronger in keeping systems alive by resistance to attack, and “bad coins” would be much more difficult to kill once started.
It also sounds like PoS could be adapted to this use. I would prefer blind last transaction Time * transactions. So Reputation is given to longer unspent transactions not the quantity of coins owned.
-
Whenever a massive debate or feature is set up, that triggers a doubt. Linus Torvalds has a rule: If you have more than three nested blocks of code, you’re doing it wrong.
I feel like we’re patching something that needs a different way of thinking.
-
The problem of distributed checkpointing is what nodes are trusted enough to generate them and what to do if a checkpoint conflict occurs. The current implementation of ACP allows only one master node. If there are two or more of them and they checkpoint different blocks for a height given, the consequences are dire. There is no way to reset a checkpoint without either deleting the entire block chain downloaded or maybe re-compiling the daemon with a new checkpoint public key. The first step to extend this protocol is to allow several master nodes to operate in parallel and communicate without revealing themselves. I have the ideas, but no time to implement them.
-
[quote name=“wrapper0feather” post=“52926” timestamp=“1389965174”]
One argument against ACP was that it was not in the Bitcoin the paper and that Alternate currencies that should die were kept alive by ACP.
[/quote]Observation : DoS protection for Bitcoin was not in the paper (due to time?) and Bitcoin was kept alive by …
-
Another option I promoted, was a small proportional transaction fee, to be fairer to and attract more miners.
-
[quote name=“ghostlander” post=“53230” timestamp=“1390064317”]
The problem of distributed checkpointing is what nodes are trusted enough to generate them and what to do if a checkpoint conflict occurs. The current implementation of ACP allows only one master node. If there are two or more of them and they checkpoint different blocks for a height given, the consequences are dire. There is no way to reset a checkpoint without either deleting the entire block chain downloaded or maybe re-compiling the daemon with a new checkpoint public key. The first step to extend this protocol is to allow several master nodes to operate in parallel and communicate without revealing themselves. I have the ideas, but no time to implement them.
[/quote]Could Kevlar’s flux protocol be used the that communication?
Also to build a trust level, I was thinking to use the uptime of the pool nodes.
Thoughts:
[list]
[*]a single miner can’t get the hashing power to manipulate the blockchain, so only a pool could do that
[*]the longer a pool is online, the smaller is the chance, that the pool owner intends to manipulate the blockchain, as they are up to fast money
[*] all acp nodes build a list of all other acp nodes and a preference is attached to each acp node
[*]the preference is calculated on several paramerers
[list]
[*]node uptime
[*] ratio pool hashrate to total hash rate
[*] change of pools hash rate over time
[*] …
[*] …[/list]
[*]the ACP functionality could be implemented as part of the pool software
[*]pools with lower hashrate could get higher preference
[*] pools beeing online for a longer time could get higher preference
[*] pools with constant hashrate could get higher preference
[*] distributed pools (= p2pool) coud get higher preference
[*]the acp node with the highest preference rules the generation of checkpoints
[/list]Probably a lot of this - if not all- is nonsense…
Thoughts are not really sorted out…
No clue, if such a principle/process can be implemented…
Not really sure, if this really would help to secure the blockchain…comments?
-
You don’t need uptime to turn trusted pools into checkpoint masters. Let them generate pairs of keys, include the public ones in the daemon’s code and here you go. What you need is a protocol to resolve checkpoint conflicts and potential abuse. You also need a supermaster key pair capable of invalidating any of their key pairs and related checkpoints on the fly by message broadcasting. I talked about this implementation half a year ago in this forum when FTC was under attacks with no ACP at all.
-
If wie need something like a super key, we have a central authority hat can change things to own advantage and we don’t need to change/modify/improve ACP.
I tried to describe an approach to implement an additional set of rules/procedures/algorhisms to increase the security oft the blockchain without centralized authorities, as I think, it’s the idea oft crypto currencies to work without such central ‘banks’
-
[quote name=“Wellenreiter” post=“53258” timestamp=“1390071031”]
Could Kevlar’s flux protocol be used the that communication?
[/quote]You mean Link? Link uses the address system to store information. Not sure if that much info should go into addresses. My FLUX design also depends on Link. Maybe if we had a MetaCoin or PoolCoin or such.
[quote]
Also to build a trust level, I was thinking to use the uptime of the pool nodes.Probably a lot of this - if not all- is nonsense…
Thoughts are not really sorted out…
No clue, if such a principle/process can be implemented…
Not really sure, if this really would help to secure the blockchain…comments?
[/quote]The unfortunate thing is: ACP was introduced to deal with hostile and potentially suicidal attackers. They intended to lose money. We need to defend not just adapt.
-
instead if this being only for pools could we not add this to the normal client where trusted node starts out being the acp server node but is then recalculated by each node broadcasting which it thinks should be trusted based on
uptime - higher is better
hashrate - lower is better ()etc etc
essentially a primary node on the network. If we can get a consensus on the block chain why cant we get a consensus on this?
I know it would potentially suffer the same problems with a 51% but we would then have two lines of defence rather than one.
-
I don’t pretend to understand a lot of this stuff, but I’d expect to be hearing the name Leslie Lamport being thrown around. I am sure *something* he has done regarding distributed consensus would apply here - namely the Paxos related consensus.
http://en.wikipedia.org/wiki/Leslie_Lamport
http://en.wikipedia.org/wiki/Paxos_algorithm
Is there a coin that even mentions Paxos or Lamport anywhere? If there was, I’d sure jump on it (as a total CS nerd).
-
paxos is a very useful distributed voting, but it lacks one big thing for coins the notions of attacker node that is one of the problem of coins.
someone can setup millions of voting nodes to say yes so win the concensus but those node are attacker node. coin own in POS is a way to minimized this and replace it by who own more coins. the actual POW is who work hard enough to find the solution.
-
[quote name=“groll” post=“56200” timestamp=“1391141274”]
… the actual POW is who work hard enough to find the solution.
[/quote]This would give a lot of power to the ‘big wales’, a very big drawback for me.
-
[quote name=“Tuck Fheman” post=“52165” timestamp=“1389720303”]
[quote author=wrapper0feather link=topic=6861.msg52126#msg52126 date=1389711177]
“Loyal network”
[/quote]Go onnnn. What is this “loyal network” of which you speak?
[/quote]That is my cuddly name for “loyal miners” who just mine Feathercoin, and don’t try to coin hop to manipulate the Difficulty calculation.
-
[quote name=“groll” post=“56200” timestamp=“1391141274”]
paxos is a very useful distributed voting, but it lacks one big thing for coins the notions of attacker node that is one of the problem of coins.someone can setup millions of voting nodes to say yes so win the concensus but those node are attacker node. coin own in POS is a way to minimized this and replace it by who own more coins. the actual POW is who work hard enough to find the solution.
[/quote]Just saying that distributed consensus with adversaries, however defined, is fairly well researched. I am sure POS or POW can be incorporated. CCs strike me as an area ripe for application.
