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. |
|
|
|
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.
Yes, it's different. See this discussion: https://bitcointalk.org/index.php?topic=1382241.0This 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? |
|
|
|
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. |
|
|
|
Another point I think needs addressing is the votes themselves. Are they transactions? What are they? Why can't I double spend my votes?
I'll clarify how this is anticipated. Basically in hinges on votes are determined by the value you store and voting like this would destroy this value. It's like buying mining hardware and mining in opposition of tip, if you can pull it off you've destroyed your investment. |
|
|
|
RaiBlocks is unique rather than just bitcoin with voting substituted for proof of work. Whether it does what you need depends on what you intend to use it for. There's two breakage scenarios for bitcoin, one it's breaking the protocol going forward by eclipsing the network's hashing power and then there's the breaking the protocol going backwards by making longer branches going back in time. For RaiBlocks both breakage are the same. If you're using the protocol as a storage of value, breaking the protocol forward is sufficient to destroy any value held since no one will want to exchange for it. If you're looking for a generic immutable database that prints old results even if the protocol is broken going forward then RaiBlocks won't serve that purpose. The next easiest way to break both RaiBlocks and bitcoin is to convince half the network to modify their node either to vote incorrectly our just reject a block chain branch, even if it's the longest. I think with the recent evidence that even with good reason it's hard to get nodes to agree on how to change their protocol, this is an unlikely scenario for either. Of course I wouldn't try to convince anyone to not use bitcoin if RaiBlocks isn't an improvement for your use case. If nothing else this can alleviate traffic off of bitcoin where it satisfies the users needs. I'll have to think about how to quantify the agreement rate, to me it seemed pretty straight forward: nodes observe vote traffic and change their vote to match the winner. Ideally this should converge after 1 vote interval but we do 4 to account for delays or dropped packets.
One difference with this compared to PoW consensus is there's no randomness injected in to the result. In PoW if two solutions are published and one has a higher block height, that answer could change after the next block based on the randomness of who came up with a solution faster. With voting the only randomness would be from nodes making random votes rather than agreeing with who they see as the winner.
In plain PoW blockchains, the asymptotic security comes from the fact that consensus on all historic transactions is constantly being reinforced by the addition of a new block to the chain. The more blocks get added, the higher the security for any given block in the history, because changing that historic block requires re-doing all the work built on top of it. If you can add a section to your paper explaining the parallel to this, it would be helpful. |
|
|
|
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. |
|
|
|
This kind of peters out half way through? It seems to identify a set of good features for a consensus design to have, but it never goes on to explain how they are achieved - e.g. the asymptotic security. Based on some feedback in another forum I added a "Confirmation Procedure" section which goes over how a single block is confirmed either through lack of opposition + quorum or through voting. I'll have to think about how to quantify the agreement rate, to me it seemed pretty straight forward: nodes observe vote traffic and change their vote to match the winner. Ideally this should converge after 1 vote interval but we do 4 to account for delays or dropped packets. One difference with this compared to PoW consensus is there's no randomness injected in to the result. In PoW if two solutions are published and one has a higher block height, that answer could change after the next block based on the randomness of who came up with a solution faster. With voting the only randomness would be from nodes making random votes rather than agreeing with who they see as the winner. |
|
|
|
|
I haven't built one, I wasn't aware of the need. Windows 32bit? 7, 8, 8.1?
|
|
|
|
An indicator for amount of supply distributed was requested and we added it to the faucet page. https://raiblocks.net/#/startAs of right now the faucet has distributed 5,189,123 MRAI which amounts to 1.525% of total supply. |
|
|
|
any info?
supply?
algo?
etc
I updated the original post to better reflect the quick information people want to see. Let me know if there's anything else you'd like to see. |
|
|
|
Has emunie released a spec our source yet?. It seems like they're trying to do a lot, some I don't know how they'll do in a fully distributed manor ie friendly account names. We chose to focus on just the currency aspect instead of all the bells and whistles that could drag the project down. The main difference I think it's were done and source code is released. Our immediate goals are, since development is complete, getting the word out and getting users and on exchanges. If you want to help, message or tweet some exchanges and request a listing. Right now we've been talking with bittrex but they want to see community desire. We think or killer app is freemium web content. https://raiblocks.net/#/demosIt will have a fixed supply, that's correct. One decision we made was to not use decimals in the protocol. Decimals in finance are notoriously error prone, fixed point being only slightly better. Imo I don't know why any coin uses decimals. Obviously these numbers are too big to present to the user. We have a set of SI prefixes, we present the user with Mrai which divides it down by 10^30. In our design rationale page we listed we wanted to do this number for future-proofing, dealing with lost coins, etc. There was talk of using 64 bits instead of 128 but it represented a 2% change in average block size for a much larger supply. https://github.com/clemahieu/raiblocks/wiki/Design-features// SI dividers rai::uint128_t const Grai_ratio = rai::uint128_t ("1000000000000000000000000000000000"); // 10^33 rai::uint128_t const Mrai_ratio = rai::uint128_t ("1000000000000000000000000000000"); // 10^30 rai::uint128_t const krai_ratio = rai::uint128_t ("1000000000000000000000000000"); // 10^27 rai::uint128_t const rai_ratio = rai::uint128_t ("1000000000000000000000000"); // 10^24 rai::uint128_t const mrai_ratio = rai::uint128_t ("1000000000000000000000"); // 10^21 rai::uint128_t const urai_ratio = rai::uint128_t ("1000000000000000000"); // 10^18 Colin, this is great, thank you for clearing this. I agree about use of decimals - one of fresh ideas! I've recalculated coin supply according to published distribution schedule and I can't get to your published percentages - here's what I get: [MRai] 2^127 170,141,183 47.1% 2^126 85,070,591 23.5% 2^125 42,535,295 11.8% 2^124 21,267,647 5.9% 2^124 21,267,647 5.9% 2^123 10,633,823 2.9% 2^122 5,316,911 1.5% 2^122 5,316,911 1.5% ---------------------------------- TOT approx. 361,550,014 100.0% Your percentages in distribution schedule: Year 1: 2^127 50% Year 2: 2^126 25% Year 3: 2^125 13% Year 4: 2^124 6.3% Year 5: 2^124 3.1% Year 6: 2^123 1.6% Year 7: 2^122 0.8% Year 8: 2^122 0.8% What am I doing wrong? Thanks. Anyway, there will be max. approx. 360 000 000 MRai - correct ? First year - there should be approx. 170 000 000 MRai - which distributed from genesis account should amount to +-5MRai/s, +-438100MRai per day - correct ? I am asking because actual coin supply available at any moment is important metric for the network. Is there any other exact method how to calculate available coin supply real time? If I look at genesis account - 330 466 529 MRai sits there, so around 30 000 000 MRai has been already distributed to landing and then to faucet account (approx. 5 580 000 MRai sits there atm), so around 24 500 000 MRai has been distributed among other accounts - correct ? I believe your concept of separate ledgers for accounts and elimination of [wasteful]pow/[rich guy]pos securing the consensus is superior to actual gen of coins in existence atm. Time will tell if it is secure enough against external attacks, but I believe this is the way into future with crypto coins. I know only of other coin that is trying to develop similar concepts, which is eMunie. How would you compare Rai to eMunie ? Is there any other coin being developed similar in concepts ? Also, I would like to know, what are your short term plans for the Rai ? Thanks again and good luck to Rai! |
|
|
|
You identified some copy pasta, I fixed it in the wiki. I think the remaining percentage difference is just from rounding. The schedule lists the upper limit on distribution. Since we're distributing through the captcha, the actual amount in circulation is less. Indeed less than .2 percent had been distributed so far. We're going to add a indicator of the active supply to the faucet page since others want to see the same thing. I'll tweet when we add it. Hopefully tonight. It will have a fixed supply, that's correct. One decision we made was to not use decimals in the protocol. Decimals in finance are notoriously error prone, fixed point being only slightly better. Imo I don't know why any coin uses decimals. Obviously these numbers are too big to present to the user. We have a set of SI prefixes, we present the user with Mrai which divides it down by 10^30. In our design rationale page we listed we wanted to do this number for future-proofing, dealing with lost coins, etc. There was talk of using 64 bits instead of 128 but it represented a 2% change in average block size for a much larger supply. https://github.com/clemahieu/raiblocks/wiki/Design-features// SI dividers rai::uint128_t const Grai_ratio = rai::uint128_t ("1000000000000000000000000000000000"); // 10^33 rai::uint128_t const Mrai_ratio = rai::uint128_t ("1000000000000000000000000000000"); // 10^30 rai::uint128_t const krai_ratio = rai::uint128_t ("1000000000000000000000000000"); // 10^27 rai::uint128_t const rai_ratio = rai::uint128_t ("1000000000000000000000000"); // 10^24 rai::uint128_t const mrai_ratio = rai::uint128_t ("1000000000000000000000"); // 10^21 rai::uint128_t const urai_ratio = rai::uint128_t ("1000000000000000000"); // 10^18 Colin, this is great, thank you for clearing this. I agree about use of decimals - one of fresh ideas! I've recalculated coin supply according to published distribution schedule and I can't get to your published percentages - here's what I get: [MRai] 2^127 170,141,183 47.1% 2^126 85,070,591 23.5% 2^125 42,535,295 11.8% 2^124 21,267,647 5.9% 2^124 21,267,647 5.9% 2^123 10,633,823 2.9% 2^122 5,316,911 1.5% 2^122 5,316,911 1.5% ---------------------------------- TOT approx. 361,550,014 100.0% Your percentages in distribution schedule: Year 1: 2^127 50% Year 2: 2^126 25% Year 3: 2^125 13% Year 4: 2^124 6.3% Year 5: 2^124 3.1% Year 6: 2^123 1.6% Year 7: 2^122 0.8% Year 8: 2^122 0.8% What am I doing wrong? Thanks. Anyway, there will be max. approx. 360 000 000 MRai - correct ? First year - there should be approx. 170 000 000 MRai - which distributed from genesis account should amount to +-5MRai/s, +-438100MRai per day - correct ? I am asking because actual coin supply available at any moment is important metric for the network. Is there any other exact method how to calculate available coin supply real time? If I look at genesis account - 330 466 529 MRai sits there, so around 30 000 000 MRai has been already distributed to landing and then to faucet account (approx. 5 580 000 MRai sits there atm), so around 24 500 000 MRai has been distributed among other accounts - correct ? I believe your concept of separate ledgers for accounts and elimination of [wasteful]pow/[rich guy]pos securing the consensus is superior to actual gen of coins in existence atm. Time will tell if it is secure enough against external attacks, but I believe this is the way into future with crypto coins. I know only of other coin that is trying to develop similar concepts, which is eMunie. How would you compare Rai to eMunie ? Is there any other coin being developed similar in concepts ? Also, I would like to know, what are your short term plans for the Rai ? Thanks again and good luck to Rai! |
|
|
|
It will have a fixed supply, that's correct. One decision we made was to not use decimals in the protocol. Decimals in finance are notoriously error prone, fixed point being only slightly better. Imo I don't know why any coin uses decimals. Obviously these numbers are too big to present to the user. We have a set of SI prefixes, we present the user with Mrai which divides it down by 10^30. In our design rationale page we listed we wanted to do this number for future-proofing, dealing with lost coins, etc. There was talk of using 64 bits instead of 128 but it represented a 2% change in average block size for a much larger supply. https://github.com/clemahieu/raiblocks/wiki/Design-features// SI dividers rai::uint128_t const Grai_ratio = rai::uint128_t ("1000000000000000000000000000000000"); // 10^33 rai::uint128_t const Mrai_ratio = rai::uint128_t ("1000000000000000000000000000000"); // 10^30 rai::uint128_t const krai_ratio = rai::uint128_t ("1000000000000000000000000000"); // 10^27 rai::uint128_t const rai_ratio = rai::uint128_t ("1000000000000000000000000"); // 10^24 rai::uint128_t const mrai_ratio = rai::uint128_t ("1000000000000000000000"); // 10^21 rai::uint128_t const urai_ratio = rai::uint128_t ("1000000000000000000"); // 10^18 @clemahieu
Very interesting project & fresh concept with accounts ledger!
Do I read it right that first year distribution is 2^127 ? So during 1st year there will be 170,141,183,460,469,000,000,000,000,000,000,000,000.00 coins ? Seems like I got it wrong... Can you please shed some light on this + on the final coin supply (if it will have fixed supply).
Also, seems like your solution to the ledger will be better than eMunie's solution imho.
Thanks & watching
|
|
|
|
Sounds good, I'll link it in if there's a future thread. In the mean time I'm glad the search function can be used to find the information. My understanding is this is an announcement forum. Is it customary to link every thread that exists about a coin?. its called being organized and keeping everything in one place. if I write notes for a project I am working on for months, doesn't it make sense to keep all the notes together in one place? |
|
|
|
My understanding is this is an announcement forum. Is it customary to link every thread that exists about a coin?. |
|
|
|
Looks like Qihoo-360 flags the WinAmp uninstaller for the same thing.  http://forums.winamp.com/showthread.php?t=388471RaiBlocks places transactions in to ledger on an individual basis. This removes the concept of block intervals, block sizes, and all the other complicated parameters that destroy scalability. https://raiblocks.netFollow us on Twitter: @raiblocks SHA256: 47293612c19d5bfdac91f95352f318159413b387bd3e2cf314eb74fb54356317 File name: rai-7.3.1-win64.exe Detection ratio: 2 / 53 Analysis date: 2016-03-03 15:52:49 UTC ( 4 minutes ago ) Antivirus Result Update Qihoo-360 QVM20.1.Malware.Gen 20160303 Rising PE:Malware.Generic(Thunder)!1.A1C4 [F] 20160302 Careful when downloading wallet! |
|
|
|
Skepticism is admirable, specifically we claimed no confirmation **delays**, obviously we still need confirmations. Details can be found here. https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmationRaiBlocks places transactions in to ledger on an individual basis. This removes the concept of block intervals, block sizes, and all the other complicated parameters that destroy scalability. https://raiblocks.netFollow us on Twitter: @raiblocks SHA256: 47293612c19d5bfdac91f95352f318159413b387bd3e2cf314eb74fb54356317 File name: rai-7.3.1-win64.exe Detection ratio: 2 / 53 Analysis date: 2016-03-03 15:52:49 UTC ( 4 minutes ago ) Antivirus Result Update Qihoo-360 QVM20.1.Malware.Gen 20160303 Rising PE:Malware.Generic(Thunder)!1.A1C4 [F] 20160302 Careful when downloading wallet! shit ya be careful (Thunder)!1.A1C4 [F] can be a nasty trojan remote downloader that is popping up embeded into alot of files lately ;\ ya im 90% sure it's a remote downloader https://www.virustotal.com/en/file/47293612c19d5bfdac91f95352f318159413b387bd3e2cf314eb74fb54356317/analysis/i wouldnt touch this guys beside, does their post really even make sense? "eliminating confirmations and fees" --- just think about that statement pertaining to btc lol |
|
|
|
|
Show Posts
