Salmon, sardines, mackerel and certain other fatty fish are rich in omega-3 fatty acids, which are thought to lower the risk of heart disease and stroke. The benefits of eating fish may far outweigh the risk of harming your health from the mercury these fish contain, according to Harvard's T.H. Chan School of Public Health. If you worry about the contaminants your fish dinner may contain, you can try eating lower down on the food chain. Certain fish, such as sharks, swordfish, king mackerel and tilefish, contain higher levels of mercury than smaller fish, like sardines, smelt, and anchovy.
Pomegranate
https://medium.com/@venessadcruze/organifi-pure-reviews-does-it-work-ingredients-where-to-buy-and-coupon-code-ac897b6e2248
Topic: Block lattice (Read 8357 times)
What is bootstrap poisoning? (https://github.com/clemahieu/raiblocks/wiki/Attacks)
The Wiki mentions an attacker holding onto an "old private key" with a balance. What is the difference between a new private key with a balance and an old private key with a balance? A private key is a private key.
The Wiki mentions an attacker holding onto an "old private key" with a balance. What is the difference between a new private key with a balance and an old private key with a balance? A private key is a private key.
Sounds right I think, bootstrap poisoning is one attack vector. One way to address this would be to bootstrap to your representative or whoever gave you your wallet code. Presumably if you trust them enough to download and execute a program that manages your private keys, you can trust them to bootstrap you correctly.
Am I right that the majority of this thread (all the talk about storing votes on chain or not) comes down to this exact problem? A bootstrapping node can be fooled with a fork if whoever had the majority vote at the time of the fork votes differently when this new node is syncing for the first time. That brings up another question: if nodes A and B have all the voting power at block 100, but today at block 500,000 the voting power is owned by nodes C and D -- won't a new bootstrapping node, encountering a fork at block 100, ask for votes from nodes A and B? What if those nodes are so old they are offline forever by now? Or even worse if their private keys have been compromised since block 100, then anyone can trick a bootstrapping node and send them off on a new fork starting at block 100...?
Look where we are now...this thread is legendary. hahah
Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger.
So at the very least, nodes which are syncing would accept my fork as truth? Also possibly online nodes if my fork was presented within some window of time?
Sounds right I think, bootstrap poisoning is one attack vector. One way to address this would be to bootstrap to your representative or whoever gave you your wallet code. Presumably if you trust them enough to download and execute a program that manages your private keys, you can trust them to bootstrap you correctly.
Another option is to bootstrap to someone you're interested in sending to, a merchant perhaps, because in the end the only thing that matters is if they'll accept your payments as valid and they'll tell you what they're accepting through bootstrapping.
Another problem would be if almost everyone simultaneously changed their representative while forks were occurring. This would would require every account to be online and simultaneously signing a change to their representative; interesting but I don't see that actually happening.
Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger.
So at the very least, nodes which are syncing would accept my fork as truth? Also possibly online nodes if my fork was presented within some window of time?
This is also why storing historical votes is unnecessary per our previous discussion. Votes only matter when they're actively being taken off the network and weighed by the current ledger state.
This is to prevent history rewriting.
This is to prevent history rewriting.
You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.
If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.
If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.
How do they tell the difference between my fork and their fork?
Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger. Unless the stake holders from their perspective are voting for the new block, they won't evict a block.
It sounds like your describing a system where nodes compute accumulated stake in order to find a "highest branch"; RaiBlocks doesn't operate this way.
You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.
If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.
If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.
How do they tell the difference between my fork and their fork?
Rewriting history of an account can only be done by the account owner themself, representatives can't do this.
So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?
How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.
Since every account is a partition, I can present a fork where the historical stake has been sent to an account which I control before it was originally transferred somewhere else. Then I sign the fork with that same stake.
You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.
If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.
Rewriting history of an account can only be done by the account owner themself, representatives can't do this.
So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?
How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.
Since every account is a partition, I can present a fork where the historical stake has been sent to an account which I control before it was originally transferred somewhere else. Then I sign the fork with that same stake.
Rewriting history of an account can only be done by the account owner themself, representatives can't do this.
So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?
How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.
Rewriting history of an account can only be done by the account owner themself, representatives can't do this.
So, I send 100 BTC to you, wait for you to sign it to receive it. Then I purchase historical stake, and produce a historical fork where I send the same funds to another account I control, which signs it, then I use my historical voting power to vote on my fork, and viola?
Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?
It doesn't. But voting with historical stake will no doubt present the relevant problem.
This attack is feasible for systems that grafted voting on top of a bitcoin style block chain where transactions are unordered. With RaiBlocks an account signs a total order for all transactions it generates.
Rewriting history of an account can only be done by the account owner themself, representatives can't do this.
Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?
It doesn't. But voting with historical stake will no doubt present the relevant problem.
Is this different than with bitcoin?
To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.
To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.
Yes, it's different. See this discussion: https://bitcointalksearch.org/topic/proof-that-proof-of-stake-is-either-extremely-vulnerable-or-totally-centralised-1382241
This is relevant, because Raiblocks uses the PoS security model.
Since putting a block in an accounts's chain requires it to be signed by the account owner, how does the stake key holder sign blocks for an account it doesn't have the key for?
Is this different than with bitcoin?
To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.
To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.
Yes, it's different. See this discussion: https://bitcointalksearch.org/topic/proof-that-proof-of-stake-is-either-extremely-vulnerable-or-totally-centralised-1382241
This is relevant, because Raiblocks uses the PoS security model.
voting like this would destroy this value.
Why is that a problem? Take out a short on an exchange, vote like that, decrease value -> profit?
Is this different than with bitcoin?
To short bitcoin you need an investment that exceeds 50% of mining hardware cost.
To short RaiBlocks you need a 50% entire market cap investment.
If voting only happens when there is a signed fork, doesn't that mean there are no visible confirmations and if so then how does somebody receiving a payment know at which point it is safe to accept it?
Representatives make a single vote on every block they receive so the receiver can count network quorum but unless there's a conflicting block they don't vote again since there's no other candidate block to consider. In the document I added a Confirmation Procedure section to better describe how a single block is confirmed. Let me know if that clears anything up.
Oh I see. Looks interesting.
I like getting rid of the need for wasteful commercial mining without the rich getting richer aspect of PoS, although I do worry about participation both for the number of full nodes and for the number of representatives getting votes. I think i saw something about a kind of weighting to stop a single representative getting a huge amount - can you explain that more please because at the moment all I can see is 99% of users never even looking at it and therefore 99% of the votes going to whatever account the person providing the wallet sets it at.
Sure, the way I hope it will shake out it there are already groups out there who run nodes, exchanges, interest groups, banking institutions. Ideally for any wallet they control they'd have a voting representative they'd name for any accounts they control.
The number of full nodes is a concern as well, indeed as far as I know there isn't a method out there to incentivize a node for performing the essential service of reproducing the full blockchain to new nodes, at least one that can't be gamed. This was one of the reasons why we tried the no-in-chain-rewards system, mining seemed to be heavily rewarding a small group of people who perform a very specific task. If there are incentives for people to run businesses around the technology we think there's an incentive to keep the ecosystem healthy by running representatives or full nodes. At least the cost of running a full node with RaiBlocks is just bandwidth and disk space, rather than heavy CPU/GPU/mining hardware costs.
There isn't a way the protocol can determine if a single entity has disproportionate voting strength because it can't disprove account collusion; I think PoW systems have a similar issue where mining pools become disproportionately strong. I think one benefit RaiBlocks has in this aspect is account holders have zero-friction to make a change if they think a group is getting too powerful, they can simply name a new representative. Compare this with mining where the only way for me to make a mining pool less strong is to invest in mining hardware myself.
Let me know what you think.
voting like this would destroy this value.
Why is that a problem? Take out a short on an exchange, vote like that, decrease value -> profit?
Jump to: