Eliminating ACP
-
You are missing FLUX. :)
If you like Quantum Mechanics, FLUX is like a pilot wave deciding a path before any exchange of any size actually occurs.
As I’ve said a few times: The reason we have the 51% threshold is because it’s a simple send. There are no other steps, therefore there are not multiple stages of contesting the correctness of the chain.
Solution: More stages, nuances to the interaction naturally raise the threshold.
-
[quote name=“Kevlar” post=“51938” timestamp=“1389658026”]
So it occurred to me that ACP could be eliminated in favor of decentralized check-pointing.All you would have to do is have the client disallow reorgs above a certain height. In effect, every node becomes the checkpointer. You would have all the protection of ACP (no reorgs allowed beyond a certain height), with none of the centralization.
The impact of this is that someone could have 99% of the mining power, and could mine longer chains all they want, and if they waited to broadcast them beyond a certain height, they would all be rejected.
I must be missing something. What is it?
[/quote]Is there an example of this in use?
-
[quote name=“Tuck Fheman” post=“51944” timestamp=“1389659009”]
[quote author=Kevlar link=topic=6861.msg51938#msg51938 date=1389658026]
So it occurred to me that ACP could be eliminated in favor of decentralized check-pointing.All you would have to do is have the client disallow reorgs above a certain height. In effect, every node becomes the checkpointer. You would have all the protection of ACP (no reorgs allowed beyond a certain height), with none of the centralization.
The impact of this is that someone could have 99% of the mining power, and could mine longer chains all they want, and if they waited to broadcast them beyond a certain height, they would all be rejected.
I must be missing something. What is it?
[/quote]Is there an example of this in use?
[/quote]Not that I know of.
You see, it’s considered bad for blockchains to not allow miners to reorg the chain. That’s what ACP does: It says: “Oh, the blockchain has reached height X? I’ll send a checkpoint to everyone saying that block X minus N is the ‘official’ block in the chain.” and clients won’t accept a reorg that doesn’t include that block at that height.
If the clients did this on their own, they wouldn’t need ACP to tell them to. There’s no reason that I can see to have ACP decide when the clients are seeing the same thing ACP is. The clients can generate their own checkpoints after a certain height, just like ACP does, and then ACP is eliminated.
Right?
-
[quote name=“Kevlar” post=“51946” timestamp=“1389659540”]
If the clients did this on their own, they wouldn’t need ACP to tell them to. There’s no reason that I can see to have ACP decide when the clients are seeing the same thing ACP is. The clients can generate their own checkpoints after a certain height, just like ACP does, and then ACP is eliminated.Right?
[/quote]Assuming (and I am) someone is competent enough to accomplish said task in code, I see no reason why not. Then again, I understand the blockchain about as well as I understand women.
-
[quote name=“Kevlar” post=“51946” timestamp=“1389659540”]
If the clients did this on their own, they wouldn’t need ACP to tell them to. There’s no reason that I can see to have ACP decide when the clients are seeing the same thing ACP is. The clients can generate their own checkpoints after a certain height, just like ACP does, and then ACP is eliminated.
Right?
[/quote]The problem is guaranteeing that every client sees the same thing. We know this is not the case because of chain forks that occur when difficulty is too low. There is no ACP (spoon). There are only clients following some sort of consensus.
Which is why I mention the need for a kind of pilot wave. No transaction should be allowed that doesn’t follow a kind of ghost history that already exists and is equivalent in some way. This pilot wave idea isn’t new. The transaction chain is stuffed into the blockchain. For P2Pools the transaction chain guzzinta the share chain guzzinta the blockchain. The key might be modeling ACP after P2Pool dynamics.
-
[quote name=“zerodrama” post=“51957” timestamp=“1389662229”]
[quote author=Kevlar link=topic=6861.msg51946#msg51946 date=1389659540]
If the clients did this on their own, they wouldn’t need ACP to tell them to. There’s no reason that I can see to have ACP decide when the clients are seeing the same thing ACP is. The clients can generate their own checkpoints after a certain height, just like ACP does, and then ACP is eliminated.
Right?
[/quote]The problem is guaranteeing that every client sees the same thing. We know this is not the case because of chain forks that occur when difficulty is too low. There is no ACP (spoon). There are only clients following some sort of consensus.
Which is why I mention the need for a kind of pilot wave. No transaction should be allowed that doesn’t follow a kind of ghost history that already exists and is equivalent in some way. This pilot wave idea isn’t new. The transaction chain is stuffed into the blockchain. For P2Pools the transaction chain guzzinta the share chain guzzinta the blockchain. The key might be modeling ACP after P2Pool dynamics.
[/quote]You don’t need to guarantee that everyone sees the same thing at all. You just need 51% of the network to be well connected. Reorgs can and should still happen, just not after a certain height. Below that height, ACP does nothing, and above that height, everyone checkpoints and won’t reorg, just like with ACP, except without ACP.
Also I have no idea what a pilot wave is, or how it would work, or why it’s necessary. The protocol works fine as is. Any traffic on the network would only increase latency and allow for more reorgs, and that’s counterproductive.
-
[quote name=“Kevlar” post=“52023” timestamp=“1389681664”]
You don’t need to guarantee that everyone sees the same thing at all. You just need 51% of the network to be well connected.
[/quote]Hmm. This would be because even if multiple forks are the same height, it’s first come, first served.
[quote]
Reorgs can and should still happen, just not after a certain height. Below that height, ACP does nothing, and above that height, everyone checkpoints and won’t reorg, just like with ACP, except without ACP.
[/quote]So in every block window (say 10 blocks), block height + x < block height + limit, the past can be altered. But x > limit it can’t. Between block 1000 and 1010, after block 1004, 1000 - 1004 cannot be reorg’d. Am I reading this right?
[quote]
Also I have no idea what a pilot wave is, or how it would work, or why it’s necessary. The protocol works fine as is. Any traffic on the network would only increase latency and allow for more reorgs, and that’s counterproductive.
[/quote]This was an old attempt at explaining entanglement. People thought particles produced waves ahead of their motion and then had to follow the path allowed by those waves.
-
[quote name=“zerodrama” post=“52034” timestamp=“1389688692”]
[quote author=Kevlar link=topic=6861.msg52023#msg52023 date=1389681664]
You don’t need to guarantee that everyone sees the same thing at all. You just need 51% of the network to be well connected.
[/quote]Hmm. This would be because even if multiple forks are the same height, it’s first come, first served.
[/quote]Which is why this, in theory, would fail: Because presumably it’s possible that a minority checkpoints a different chain, and never get’s back on the longest chain, creating a fork, which is why you need centralization to disambiguate, because you’ve eliminated majority consensus.
So who here can remind me of why eliminating majority consensus is desirable?
-
[quote name=“Tuck Fheman” post=“51950” timestamp=“1389660109”]
Assuming (and I am) someone is competent enough to accomplish said task in code, I see no reason why not. Then again, I understand the blockchain about as well as I understand women.
[/quote]I have mentioned in the past here that I would like to see ACP become “DCP” but to be honest I really don’t know or understand the technology enough.
[quote author=Kevlar link=topic=6861.msg52035#msg52035 date=1389688966]
So who here can remind me of why eliminating majority consensus is desirable?
[/quote]It stifles advancement?
-
[quote name=“Calem” post=“52037” timestamp=“1389689549”]
[quote author=Tuck Fheman link=topic=6861.msg51950#msg51950 date=1389660109]
Assuming (and I am) someone is competent enough to accomplish said task in code, I see no reason why not. Then again, I understand the blockchain about as well as I understand women.
[/quote]I have mentioned in the past here that I would like to see ACP become “DCP” but to be honest I really don’t know or understand the technology enough.
[quote author=Kevlar link=topic=6861.msg52035#msg52035 date=1389688966]
So who here can remind me of why eliminating majority consensus is desirable?
[/quote]It stifles advancement?
[/quote]Well I understand the tragedy of the commons. I was referring to the blockchain protocol though. You know, that place where you actually want consensus?
-
[quote name=“Kevlar” post=“52035” timestamp=“1389688966”]
[quote author=zerodrama link=topic=6861.msg52034#msg52034 date=1389688692]
[quote author=Kevlar link=topic=6861.msg52023#msg52023 date=1389681664]
You don’t need to guarantee that everyone sees the same thing at all. You just need 51% of the network to be well connected.
[/quote]Hmm. This would be because even if multiple forks are the same height, it’s first come, first served.
[/quote]Which is why this, in theory, would fail: Because presumably it’s possible that a minority checkpoints a different chain, and never get’s back on the longest chain, creating a fork, which is why you need centralization to disambiguate, because you’ve eliminated majority consensus.
So who here can remind me of why eliminating majority consensus is desirable?
[/quote]Because massive hash power literally just lurks now. Majority consensus can come from one individual or a rogue pool and the reflex most people have is to stop mining instead of mining more, which is what the original UNOCS plan was. This makes the situation even more dangerous even for established coins. One of the nagging issues with the whole cryptocurrency concept is the need to keep banging at old transactions and to keep going when no one is sending. I mentioned months ago on demand mining, but until FLUX is done I haven’t the slightest clue how. I have a vague idea, which with the right mojo could be revolutionary, but I need to study up on crypto algos.
-
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.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?
Edit:
Im not sure if any of these ideas are even possible. But one option would be for each node to maintain a cache of all known nodes distributed in the same way as the block chain that have been active on the network for x hours then get a vote after every block / period of time on the “safe” block which essentially be current block minus 3?
This would put more load on the network and that list of all nodes could be pretty large. -
I think it’s important that we don’t assume that any would be attacker is falling asleep at wheel and we should be constantly looking for ways to protect the blockchain and innovate on the coin to stay relevant. Can we set up a test net and try this out?
-
Wow Chris, great idea.
Someone was asking for test coins.
Can we also try my 3 temporal zone difficulty averaging as well? I think it will reduce the need for ACP as the “Loyal network” will automatically control the long term block production rate.
Or some other non-ASIC freindly algorythms?
Perhaps we could implement colored test coins and please those guys as well?
-
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.
