You're quite economic with providing exact details of how your protocol behaves, I have to make guesses.
If I understand correctly, you now say the proof-of-work will be used just to bring new coins into existence, and protection from double-spending will be done just via proof-of-stake?
What makes you think that large stakeholders couldn't easily prepare a secret forked branch when they wish to double-spend? Isn't it true that generating a proof-of-stake block on demand is easier if you're a large stakeholder?
That's basically comparable to a 51% attack on proof-of-work. They would stand to lose a lot more than they gain. Why is it comparable? PoW is costly, PoS is costless. Are you saying that your protocol is less secure than pure-PoW, and that's the price to pay for energy-efficiency? I'm still throwing darts randomly, pending detailed description of your protocol. |
|
|
|
|
I'd like to raise two additional issues that weren't mentioned in coblee's OP, mainly because we missed gmaxwell's suggestion to use the key homomorphism feature of ECDSA to delegate signing keys.
In terms of economics/philosophy, maybe it's preferable that stakeholders are taxed instead of rewarded, meaning that (say) 0.5 coins of the block reward is taken from the address of the stakeholder, unless he provides the PoA signature. Technically this can be implemented by creating the coinbase txn (e.g. after 120 blocks) that spends those 0.5 coins, simply as a rule that the distributed network follows, without requiring the stakeholder's privkey. We might wish to require that the PoA txn of the stakeholder references the block that he signs, otherwise an attacker could include txn by this stakeholder in his competing fork (if the attacker was lucky enough to derive this stakeholder address in his fork). If the stakeholders participate and provide their PoA signatures, then they aren't taxed.
If we delegate signing keys, there's a security risk (that coblee raised) where people would give their signing key to some central entity that would do the signing for them, either because they don't run a node on their computer 24/7, or because the central entity offers them financial benefits. The central entity could then use its signing power for double-spending attacks. Opinions?
|
|
|
|
|
Hello killerstorm,
What do you mean by "it is not necessary to have a full block to make a signature" ? In coblee's protocol, the winning address (that should provide the PoA signature by spending the reward) is derived from the block hash, so how could you provide the PoA signature before you solved the block?
Are your concerns also apply to canicula and Meni's protocols? So far it seems to me that the only relevant distinction in Meni's protocol is that he proposed voting weights for PoS signatures, which have the property that we can penalize an address that attempted to sign more than one fork, by zeroing its weight. Implementing voting weights is complex and probably involves computationally intensive calculations by all the network nodes. But it might be possible just to penalize an address that attempted to provide PoA signatures in more than one fork, by including the evidence that it signed another fork in the blockchain (same issue arises with Meni's voting weights idea). This idea should be investigated if there plausible attack scenarios (perhaps your scenario). We shouldn't assume that the majority of stakeholders is malicious, but we should assume that the majority is rational.
|
|
|
|
Hello gmaxwell, So, one point thats a minor engineering thing but important is that you should _not_ be using the same key for currency transactions and mining, because it's reasonable and prudent to keep large volumes of coins offline or at least encrypted. There are a bunch of ways to do this (persistent delegations, one time delegations, ECC math related keys) which have different consequences; I think it's just important to do one.
With delegations, it has to involve linkage of the two pubkeys at some block on the chain, and all nodes would continuously have to look at the old block where the linkage was established to verify it. With ECC math related keys, did you mean something similar to type-2 deterministic wallet? Meaning that the seed is blank or known to all, everyone can derive pubkey2 from pubkey1, but only the person who holds privkey1 can derive privkey2 and then use privkey2 (stored unencrypted) to create PoS signatures? This idea is actually quite neat, like deterministic wallet it's secure as long as the PRF is pesudorandom, and there's no need to bloat the blockchain with linkages. Edit: Hmm, I was wrong. If the seed is known to all, privkey2 is stored unencrypted, and some hacker steals wallet.dat and obtains privkey2, then he can simply do privkey2-hash(seed,...) to get privkey1 and spend the coins. gmaxwell, what did you mean by ECC math related keys? Lets say there exists a pair of short competing forks. There is an earlier fork, the one you heard first and a competing later one. Network convergence demands you sign the earlier one, but you're not the chosen miner for the blocks there. You are, however, a chosen node in the weaker fork. You (like almost all users) have no transactions that would be reversed by mining in one over the other.... so you confirm the weaker one because _doing so cost you nothing, and in the event that it does win, you get more coin that way, so doing so is the rational action_. Your choice isn't "Fork A" or "Fork B", it's "sign" or "do nothing" _independently_ on each fork you're permitted to sign, and signing costs you nothing and has a non-zero expected return. With PoW you're burning a finite resource on your preferred choice, and you can't simultaneously mine multiple forks without diluting your resources.
This happens is because your stochastic PoS has the property that the existence of a fork expands the network wide pool of stake producing capacity. At least, opposed to some other schemes, creating that fork still requires a POW investment so at least thats good.
But isn't it true that in coblee's proposal you would see both "Fork A" and "Fork B", because the protocol allows for a time period (120 blocks in his example) in which you may do your PoS? Perhaps it might be a good idea for the protocol to enforce that you also wait at least N<120 blocks before you are allowed do your PoS (i.e. spend your reward in this proposal), to avoid the default behavior of stakeholders who'd sign too quickly the first fork that they see, which might not be the best fork because of network propagation/isolation issues ?
This idea is supposed to provide security from an attacker who only has large hashpower, so his fork would lose because he doesn't control the privkeys that should do the PoS by spending the rewards. If I understand correctly, you agree that this protocol gives better security from attackers who only have large hashpower, but claim that there are new risks that involve malicious stakeholders who could try to attack?Edit: what I wrote here is nonsense, it applies to Meni's protocol, not to lottery-based protocols. The correct answer is in post #82 etc. |
|
|
|
Double spending will be hard exactly the same way as in Bitcoin, because generating one proof-of-stake block on demand is already hard, generating multiple of them to force reorg is way way harder.
Energy-efficiency is still preserved if proof-of-work blocks get scored 0.
You're quite economic with providing exact details of how your protocol behaves, I have to make guesses. If I understand correctly, you now say the proof-of-work will be used just to bring new coins into existence, and protection from double-spending will be done just via proof-of-stake? What makes you think that large stakeholders couldn't easily prepare a secret forked branch when they wish to double-spend? Isn't it true that generating a proof-of-stake block on demand is easier if you're a large stakeholder? |
|
|
|
The main chain protocol will now score based on proof-of-stake difficulty.
Please elaborate? Neither your article nor your previous replies were clear enough, and I didn't try to analyse the source code just to understand the protocol specifications. If I understood correctly, the blockchain can be extended either by proof-of-work or by proof-of-stake as the next block? My guess is that since the main property that your protocol tries to accomplish is to avoid the energy waste of proof-of-work hashpower, you won't be able to achieve security from double-spending attacks by stakeholders. It's an interesting experiment, we'll see if I'm wrong... |
|
|
|
The centrally broadcasted checkpoints mechanism sounds like an extremely bad idea, do you concede that the entity that controls this mechanism can easily mount double-spending attacks? The whole point of proof-of-stake is that the stakeholders would establish the checkpoints in a distributed fashion, which can be done.
Luke-Jr, how come this centrally broadcasted checkpoints mechanism passed your scam smell-test so easily? Their paper admits this is a problem, and implies it is temporary. Well, the paper admits that they don't know how to solve this problem with their protocol. I also don't see how to do decentralized checkpoints with their protocol, but we do know how to do it with Meni's protocol. Either way, that's not the fundamental problem of this proof-of-stake protocol. The fundamental problem is that stakeholders can mount double-spending attacks effortlessly. |
|
|
|
From the whitepaper: The block chain with highest total consumed coin age is chosen as main chain. I'd have to think about it a lot harder than I'm willing to right now to be absolutely sure, but that seems like a mistake to me. If peers have to fetch inputs and compute coin age to determine whether or not a chain is longest then it seems like that could be leveraged into a denial-of-service attack. Because an attacker could do minimal proof-of-work (or proof-of-stake) but then broadcast a chain with JUST a little-less consumed coin age than the current best chain. Their chain will be rejected, but their peers will waste time figuring out that it should be rejected. DoS attacks is only a secondary problem with this proof-of-stake proposal, the main problem is that this protocol is unsound because it's susceptible to easy double-spending attacks by stakeholders, simply by releasing a forked branch with higher total consumed coin age. As discussed earlier: https://bitcointalk.org/index.php?topic=99735.msg1112992#msg1112992https://bitcointalk.org/index.php?topic=101820.msg1115868#msg1115868 |
|
|
|
|
Hello Sunny King,
So a stakeholder (without investing in any high-hashpower hardware) could try to mount a double-spending attack and reverse a txn before the next checkpoint, by broadcasting a secret forked branch that he prepared with a higher total consumed coin age (a.k.a. BDD) ? Have you tried to analyse the potential for double-spending attacks in this protocol?
The centrally broadcasted checkpoints mechanism sounds like an extremely bad idea, do you concede that the entity that controls this mechanism can easily mount double-spending attacks? The whole point of proof-of-stake is that the stakeholders would establish the checkpoints in a distributed fashion, which can be done.
Luke-Jr, how come this centrally broadcasted checkpoints mechanism passed your scam smell-test so easily?
|
|
|
|
The security issue raised by large balance hot wallets could be dealt with as follows:
1) Create special account used for signing blocks
account restricted to two valid functions: 1) Sign blocks using coins in special account
2) Release coins in special account to user-specified normal account (specified address set permanently when special account is created)
2) Special account is held in hot wallet.
3) User-specified normal account is held offline.
Good idea. I've described a similar suggestion for PoS protocol design outline on MeniRosendfeld's wiki talkpage at https://en.bitcoin.it/wiki/User_talk:Holy-Fire, so I'll also quote the relevant part here: We basically want a digital signatures scheme in which the keygen generates a triple (privkey1,privkey2,pubkey0) where privkey1 and privkey2 are unrelated to each other, you can sign either with privkey1 or with privkey2, and verify the resulting signature with pubkey0. It'd be used for PoS by using privkey1 to do actual txns and using privkey2 only for providing the PoS signatures to the signatures blocks. This means that if privkey2 gets stolen then it doesn't amount to much, you can transfer your bitcoins to another address and re-generate a new privkey2 for it, so it's ok to store privkey2 in the clear.
We cannot implement this scheme directly with ECDSA, but we can do something that's pretty close: simply by having two pairs (privkey1,pubkey1) and (privkey2,pubkey2) and linking between them, e.g. by signing with privkey1 a message that says that pubkey2 is the public key of your 2nd pair, and from then on you can start using privkey2 to provide the PoS signatures.
What it would mean for the blockchain is that when you provide a STAKEMSG, there would be an additional field that you can include in it, and this field would contain pubkey2, meaning that starting from the next checkpoint block you are allowed to use privkey2 in order to provide signatures for the address that's controlled by privkey1.
The pubkey that would be extracted from subsequent STAKEMSGs is pubkey2 rather than pubkey1, therefore in order to tell how many bitcoins are controlled by those STAKEMSGs we store in every STAKEMSG an additional field that specifies the height of B->count relative to the block in which pubkey1 and pubkey2 were linked (and then the protocol rule would be that only this particular linkage should be respected). If we use e.g. 3 bytes for the relative height field, then privkey1 will be needed to create a new linkage block after about 320 years (assuming 10min blocks).
Note: if the pubkey2 field of STAKEMSG is empty then the signature field of STAKEMSG signed just B->hash, and if the pubkey2 field of STAKEMSG isn't empty then the signature field of STAKEMSG signed "B->hash + pubkey2".
With ECDSA signatures are 512 bits and compressed pubkeys are 258 bits, so it's not so bad because the STAKEMSGs with the extra pubkey2 field would be infrequent. In fact, we can save more space by defining the protocol so that only hash(pubkey2) is put in the extra field, because of the feature of ECDSA that you can extract pubkeys from signatures. This means that the extra field can be just (say) 128 bits hash, but more computing power will be needed to verify the signatures blocks.
This means that you wouldn't need to enter your passphrase in order to provide PoS signatures, so that the client app can work automatically, as preferred.
See the rest at https://en.bitcoin.it/wiki/User_talk:Holy-Fire#Proof_of_Stake_design_outlineYou said "specified address set permanently when special account is created". In case it's a protocol that extends the existing Bitcoin protocol, the linkage between this special address and its corresponding locked normal address will have to be put in the blockchain, so whenever the special address wishes to transfer some of its coins to the locked normal address, all the nodes must look at the old block where the linkage was made in order to verify it. Therefore I'm not sure whether your suggestion is more efficient than my suggestion. There could also be disadvantages from the user's standpoint, because he has to transfer his coins before he can spend them. Regarding Gavin's DoS concerns, in the simple PoS design outline that I described it's handled by hardcoded cutoff constant, meaning that an address cannot provide a PoS signature if it holds less coins than the cutoff amount. This is need also in order to prevent bloat in the blockchain, otherwise anyone with 1 satoshi could try to provide PoS signatures... |
|
|
|
|
Yes obvious scam, and even if it was legit there's a risk that a Litecoin hard fork to use more intensive scrypt params would render such FPGAs useless.
|
|
|
|
|
OK cool, anyhow for bcrypt/scrypt comparison see for example the chart near the end of scrypt-slides.pdf
|
|
|
|
OK, apologies, when I read this part of your first post, * Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
I wrongly assumed that the discussion is still generally related to the Bitcoin protocol framework, and took your comment to mean that as a standalone claim you're saying that cementing a checkpoint could be done without proof-of-stake. I didn't realize that you claim that these ideas hold for a substantially different protocol that doesn't use hashpower for proof-of-work etc., sorry for my confusion. |
|
|
|
Do not make the classic mistake of storing passwords using md5, sha1, sha256, sha512 etc. These are fast hashes, you need to use a slow hash.
Bcrypt is your best option. Bcrypt forces you to salt, and introduces a work factor, which allows you to determine how expensive the hash function will be.
Just curious, why bcrypt and not scrypt? Have you read the scrypt article/slides? |
|
|
|
I'm asking about the basic concept, please avoid the added complexities of cementing 6 consecutive blocks and consider the proof-of-stake cementing of the 100th signatures block. With proof-of-stake, we can cement the (say) 100th block with signatures that cannot be faked by an attacker with 51% hashpower, so everyone can protect themselves from a double-spending attack by waiting past the checkpoint signatures block in order to be sure that the relevant transactions couldn't be reversed. "rah rah rah my idea is better and I won't read what you've written throughout the thread or attempt to understand because clashes in the face of what I think is right so I will therefore treat you like an idiot" I use the word "cement" or "solidify" to represent the idea that the distributed network arrives to an agreement on a special checkpoint block that won't be reversed, which determines the true blockchain even if a 51% attacker prepared the branch that ends in a special checkpoint block. If the word "cement" also has other meanings, please choose a different word for what I described to be sure that we discuss the same thing. It's true that I haven't read yet your other ideas, because I'm trying to understand first whether your ideas solve the same problem or different problems. If you'd be so kind, please answer the basic question: do you have a suggestion regarding how to cement a checkpoint block (that cannot be reversed by 51% attack) in a way that doesn't require proof-of-stake? I don't claim that there isn't such a way, I've tried to think of another way to do it for several minutes, but didn't come up with anything. If your ideas are orthogonal and try to solve/improve other properties of the Bitcoin protocol, what are the (supposed) deficiencies of Bitcoin that you're trying to improve? Is it waste of energy of PoW, or other deficiencies? |
|
|
|
|
I don't understand, are you suggesting that each node will simply cement after seeing 6 consecutive blocks? That would cause the blockchain to fork into many branches that will never reunite.
I'm asking about the basic concept, please avoid the added complexities of cementing 6 consecutive blocks and consider the proof-of-stake cementing of the 100th signatures block. With proof-of-stake, we can cement the (say) 100th block with signatures that cannot be faked by an attacker with 51% hashpower, so everyone can protect themselves from a double-spending attack by waiting past the checkpoint signatures block in order to be sure that the relevant transactions couldn't be reversed. Do you claim that it's possible to cement a checkpoint block (with this desirable property of protecting from an attacker with 51% hashpower) without proof-of-stake? How?
What is LDD? Litecoin Days Destroyed? How is it relevant?
|
|
|
|
One question that keeps coming up to me in this debate about proof of stake:
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
It's a free market, you collect fees by signing the special checkpoint blocks, so you should evaluate the risk of your wallet being stolen versus the reward. I suppose that with grandma's PC it's better to skip trying to collecting signing fees, but for someone with a properly secure computer it should be fine. In one sense having an incentive to keep coins under your control and continuously use them actually contributes to the health of the network, because with Bitcoin there appears to be a trend to send your coins to 3rd-parties that (supposedly) give you high interest or simply the convenience of using an online wallet, and this should be even more risky than someone hacking into your personal computer. |
|
|
|
* Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
How do you cement a checkpoint block without proof-of-stake? |
|
|
|
|
Show Posts
