|
Would it be difficult to implement a Ledger Wallet compatible withe some alt-coins like Peercoin?
It would be very interesting to have a Peercoin compatible Ledger Wallet configured to only sign coinstake transactions.
We could plug it on a Raspberry Pi for example to obtain a highly securised minting full node. We wouldn't need cold minting anymore.
What do you think?
|
|
|
|
Maybe it doesn't need to because it uses coinage.
No, it's not related. Most PoS coins if not all don't use hash of block header to avoid that. so it's hashing the transactions not the header in the code you posted. You're getting lost in the minutiae. It's hashing the stake transaction which is at minima 30 days old yep. |
|
|
|
Maybe it doesn't need to because it uses coinage.
No, it's not related. Most PoS coins if not all don't use hash of block header to avoid that. |
|
|
|
Well as I said, PPC is a different implementation, using coinage. Every poS coin must use some deterministic process (it cannot be random because there would no one trusted to produce random numbers in a distributed system). but let's say you're not using coinage...let's just say for example that your process is this: HASH(staking address + blockheader +timestamp) * staking balance must be greater than some target. The attacker just keeps trying different block headers until he gets a block. Then he repeats until his chain as is long as desired. The peercoin white paper says this: However an important difference is that the hashing operation is done over a limited search space (more specifically one hash per unspent wallet-output per second) instead of an unlimited search space as in proof-of-work, thus no significant consumption of energy is involved. However, this idea of limiting the search space doesn't work when you can create endless combinations of inputs. Peercoin doesn't hash the block header, here is an excerpt of a code comment: https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/kernel.cpp#L293hash(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime) txPrev is the stake transaction, nTime the timestamp of the block we are creating (in seconds). nStakeModifier is the result of a complex scramble computation to make it very difficult to precompute future proof-of-stake at the time of the coin's confirmation |
|
|
|
I think the same basic problem remains. The attacker just stores up stake age while everyone else is constantly forging.
We said we are not taking coin age into account here, coinage is absolutely not needed for PoS to work, Peercoin has it only for some kind of incentive to mint or something... so then you are saying every coin has equal chance to stake , regardless of age. That's the idea, but no regardless of quantity. In that case there must be some deterministic process for qualification to stake and the attacker just computes chains and keep trying them. He can try endless combinations sending different coins to himself and also take advantage of the fact that there must be some kind of decreasing target. Could you be more precise please? I would like to map your attack scheme to Peercoin. |
|
|
|
I think the same basic problem remains. The attacker just stores up stake age while everyone else is constantly forging.
We said we are not taking coin age into account here, coinage is absolutely not needed for PoS to work, Peercoin has it only for some kind of incentive to mint or something... so then you are saying every coin has equal chance to stake , regardless of age. That's the idea, but no regardless of quantity. |
|
|
|
I think the same basic problem remains. The attacker just stores up stake age while everyone else is constantly forging.
We said we are not taking coin age into account here, coinage is absolutely not needed for PoS to work, Peercoin has it only for some kind of incentive to mint or something... |
|
|
|
Can you tell me in 1 simple sentence, in plain english (no links to code please):
If you remove coinage, what determines the best chain?
stake coin-days consumed How is that different from coinage? Is it the total stake owned and regardless of whats in the transactions of the chain? Or what? Yep exactly, it's the number of coins in the stakes you use to mint. No -days coz we are not taking time weight into account here. |
|
|
|
Can you tell me in 1 simple sentence, in plain english (no links to code please):
If you remove coinage, what determines the best chain?
stake coin-days consumed |
|
|
|
Yes there is coin age and a target that decreases (presumably so that it's progressively easier to find a block: the network doesn't get stuck).
What does that have to do with preventing alternate chains?
Sure 10% is smaller than 90%, however not all the transactions in a chain are going to be using all the stake/coin age at any given time, plus its possible for the 10% to have more stake age than the 90%... Seems to me the attacker simply has to wait for the right moment while checking the blockchain constantly with a program.
To explain it more clearly: The issue for the 90% who wants to stop the attacker is that if they are constantly sending coins to each other, then none of their coins gain much age. And if they save up coin age, those coins aren't used in a transaction until they are used, so the attacker can sneak in before that. Very hard to set up a system where there's no "holes", even if all the participants are cooperating.
To simplify things, let's say that there is no coin age involved, as suggested by @achimsmile in a previous post. It's a simple constant to change in the source code anyway. Could you try to explain to me a bit more in detail in what circumstances the alternate chains could get a chain trust superior to the network one? To be successful do we agree that these alternate chains should be at least 6 blocks long? If there's no coin age, then its a totally different implementation right? So "how to get a superior chain" depends on how the protocol defines it. In fact you could totally remove coinage from Peercoin without changing implementation. Just set STAKE_MAX_AGE = STAKE_MIN_AGE +1 and you'll get a time weight of 1: https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/kernel.cpp#L328The "how to get a superior chain" is described in detail in the Peercoin chain trust wiki page. In Peercoin block chain trust is calculated by adding current block trust to previous block chain trust. As described in the wiki page block trust is directly related to the minted stake coin-days. I guess we agree that these alternate chains should be at least 6 blocks long. I think you may be missing my point. Even if the change is a single line of code in a config file, or whatever, by eliminating coinage as a security component, the implementation of PoS changes, thus changing how the coin would be attacked. Talking about different implementations can be very draining and go on forever. You are already talking in circles because first you suggested removing coinage, then I told you if you did that, the superior chain would be based on the protocol rules, and then you referred me back to the peercoin rules which do use coinage. To make it clear: Either the code as implemented considers coin age or it doesn't. If it doesn't, then there would have to be an alternate method of deciding what chain is best. I'm removing coin age just to concentrate on the potential weaknesses that could exist for Peercoin besides the coinage one. As I told you it's really easy to remove coinage from Peercoin rules just Neucoin did, just two characters to change, don't tell me that is a totally different story or you'll deceive me there. Coin protocols keep evolving everyday, Peercoin has evolved a lot, v5 of the protocol will be release in the coming weeks, so let's be open and continue to investigate further. We still need to write down that concrete attack scenario against a "without coinage" Peercoin protocol version X  |
|
|
|
Yes there is coin age and a target that decreases (presumably so that it's progressively easier to find a block: the network doesn't get stuck).
What does that have to do with preventing alternate chains?
Sure 10% is smaller than 90%, however not all the transactions in a chain are going to be using all the stake/coin age at any given time, plus its possible for the 10% to have more stake age than the 90%... Seems to me the attacker simply has to wait for the right moment while checking the blockchain constantly with a program.
To explain it more clearly: The issue for the 90% who wants to stop the attacker is that if they are constantly sending coins to each other, then none of their coins gain much age. And if they save up coin age, those coins aren't used in a transaction until they are used, so the attacker can sneak in before that. Very hard to set up a system where there's no "holes", even if all the participants are cooperating.
To simplify things, let's say that there is no coin age involved, as suggested by @achimsmile in a previous post. It's a simple constant to change in the source code anyway. Could you try to explain to me a bit more in detail in what circumstances the alternate chains could get a chain trust superior to the network one? To be successful do we agree that these alternate chains should be at least 6 blocks long? If there's no coin age, then its a totally different implementation right? So "how to get a superior chain" depends on how the protocol defines it. In fact you could totally remove coinage from Peercoin without changing implementation. Just set STAKE_MAX_AGE = STAKE_MIN_AGE +1 and you'll get a time weight of 1: https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/kernel.cpp#L328The "how to get a superior chain" is described in detail in the Peercoin chain trust wiki page. In Peercoin block chain trust is calculated by adding current block trust to previous block chain trust. As described in this Peercoin wiki page block trust is directly related to the minted stake coin-days. I guess we agree that these alternate chains should be at least 6 blocks long. |
|
|
|
Yes there is coin age and a target that decreases (presumably so that it's progressively easier to find a block: the network doesn't get stuck).
What does that have to do with preventing alternate chains?
Sure 10% is smaller than 90%, however not all the transactions in a chain are going to be using all the stake/coin age at any given time, plus its possible for the 10% to have more stake age than the 90%... Seems to me the attacker simply has to wait for the right moment while checking the blockchain constantly with a program.
To explain it more clearly: The issue for the 90% who wants to stop the attacker is that if they are constantly sending coins to each other, then none of their coins gain much age. And if they save up coin age, those coins aren't used in a transaction until they are used, so the attacker can sneak in before that. Very hard to set up a system where there's no "holes", even if all the participants are cooperating.
To simplify things, let's say that there is no coin age involved, as suggested by @achimsmile in a previous post. It's a simple constant to change in the source code anyway. Could you try to explain to me a bit more in detail in what circumstances the alternate chains could get a chain trust superior to the network one? To be successful do we agree that these alternate chains should be at least 6 blocks long? |
|
|
|
Here is what I have summarized on the peercoin wiki:Let's say a greedy minter owns 10% of currently minting stakes. The greedy minter plans to construct alternate chains to attack the consensus of the network. First, it's necessary to have a good understanding of how the Peercoin chain trust mechanism works. We now know that an alternate chain will have to respect the block target calculation if it wants to be accepted by the network. This implies for example that the greedy minter won't be able to shorten the average 10 minutes PoS blocks spacing or fake the block trust. As we can see in the code below, the ability to mint (technically find a valid stake kernel hash) is directly related to the number of coin-days used for minting (bnCoinDayWeight in code below): https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/kernel.cpp#L364// Now check if proof-of-stake hash meets target protocol
if (CBigNum(hashProofOfStake) > bnCoinDayWeight * bnTargetPerCoinDay)
We know that our bnCoinDayWeight is 10% of global network coin-days. To keep up the rate of 10 minutes spacing for PoS blocks on our alternate chain, the target bnTargetPerCoinDay will have to be increased consequently and so the corresponding block trust decreased. We now understand that with 10% of minting stakes we won't be able to compete with the other 90%, our alternate chain will never be accepted as our chain trust value will be way below the network one.
|
|
|
|
guys, keep in mind that only peercoin and its derivatives use coin age. Newer PoS coins (since 2013) don't use it, because of its weaknesses.
And the algo for selecting the best chain differs in various implementations.
Hi achimsmile, I'm focusing on Peercoin here as it is the coin I know the best. I'm trying to setup a page describing the attack on the Peercoin wiki: https://wiki.peercointalk.org/index.php?title=Unlimited_alternate_chains_attack |
|
|
|
The reason why using coin age as chain priority doesn't work is that if others are beating you, (meaning their chains are accepted and yours aren't) then their coins lose their coin age while your coins keep getting older, so eventually you gain the advantage. Pretty simple I think.
May be we have a point here: coin age is maxed at 90 days in Peercoin protocol, you won't get any advantage after 90 days over other minters. https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/kernel.cpp#L328https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/main.h#L46Once you have minted a block, your coin age goes back to zero and you have to wait 90 more days if you want to have it maximized again to mint the next block. So is it possible to create a fork having a better chain trust with only 10% of the minting stakes (in our scenario, cf OP) ? That's what we need to verify. I have setup a page on the Peercoin wiki which explains the Peercoin chain trust mechanism: https://wiki.peercointalk.org/index.php?title=Peercoin_chain_trustWe can see there that the nBits block target value which is used to calculate block trust and chain trust can't be manipulated as it will be verified by receiving peers. This ensures that PoS blocks are generated every 10 minutes (on average) and that the associated difficulty/target can't be faked. |
|
|
|
So, then given that
a) Creating alternate chains attacks the network, and
b) Chains don't take signficant time to produce, and
c) the "best" chain is accepted by the network
All you need to do is keep creating chains and broadcasting
them until one is accepted.
What would prevent that?
Ok, we now need to detail the creation of one of these chains to verify if there is a chance of it being accepted by the network. It's a bit late here, so I'll do that tomorrow. Ciao. |
|
|
|
Construction of alternate chains is the way attack the consensus of the network. Do we agree on that?
Sounds ok to me. Another assumption is we use the longest chain rule for consensus. right? In PoS coins like peercoin and most forks of peercoin we use the notion of chain trust. Shorter chains may have higher chain trust. https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/main.cpp#L1808So you have some fixed formula for determining the "best" chain? Exactly, here are excerpts from the peercoin white paper: « The hash target that stake kernel must meet is a target per unit coin age (coin-day) consumed in the kernel (in contrast to Bitcoin's proof-of-work target which is a fixed target value applying to every node). Thus the more coin age consumed in the kernel, the easier meeting the hash target protocol. » « The protocol for determining which competing block chain wins as main chain has been switched over to use consumed coin age. Here every transaction in a block contributes its consumed coin age to the score of the block. The block chain with highest total consumed coin age is chosen as main chain. » http://peercoin.net/assets/paper/peercoin-paper.pdf on page 3 |
|
|
|
Construction of alternate chains is the way attack the consensus of the network. Do we agree on that?
Sounds ok to me. Another assumption is we use the longest chain rule for consensus. right? In PoS coins like peercoin and most forks of peercoin we use the notion of chain trust. Shorter chains may have higher chain trust. https://github.com/ppcoin/ppcoin/blob/v0.4.0ppc/src/main.cpp#L1808 |
|
|
|
Construction of alternate chains is the way attack the consensus of the network. Do we agree on that?
Sounds ok to me. Let's focus on one of those alternate chain then. |
|
|
|
« The basic problem with all PoS vs PoW is that it doesn't take real time to construct unlimited alternate chains which can then be used for attacks. » Here we are Jonald, let's start to build our attack scenario here. I'll try to synchronize with the wiki page simultaneously: https://wiki.peercointalk.org/index.php?title=Unlimited_alternate_chains_attackI'll also try to update the original post to synthesize things there. We need to describe step by step how it is going to happen, where do we start? First some info about our greedy minter, let's say he owns 10% of currently minting stakes, would be too easy if he owned 51% of them  The greedy minter plans to construct alternate chains to attack the consensus of the network. |
|
|
|
|
Show Posts
