RaiBlocks eliminates confirmation delays and fees bringing refreshing simplicity

[clemahieu]

RaiBlocks 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.net
Follow us on Twitter: @raiblocks

[Bank_sy]

RaiBlocks 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.net
Follow 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!

[Makingsure]

RaiBlocks 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.net
Follow 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

[clemahieu]

Feel free to recompile it and always run wallets inside a VM.

I compiled it myself, maybe scan with a reputable scanner?

[clemahieu]

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-confirmation

RaiBlocks 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.net
Follow 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

[clemahieu]

Looks like Qihoo-360 flags the WinAmp uninstaller for the same thing. http://forums.winamp.com/showthread.php?t=388471

RaiBlocks 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.net
Follow 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!

[craslovell]

Is it mineable? Any pools in existence?

[clemahieu]

Is it mineable? Any pools in existence?

We're distributing through a faucet, rate limited by a captcha.  https://raiblocks.net/#/start  The goal is to give newcomers access to Rai, not give preference to people with capital investment in mining hardware. 

Information on the distribution schedule is here https://github.com/clemahieu/raiblocks/wiki/Distribution-and-Mining  We're working on establishing a legal irrevocable trust to affirm our commitment to 0% reserves.

[truerue]

This coin already have 2 threads:
https://bitcointalk.org/index.php?topic=1248759.0
https://bitcointalk.org/index.php?topic=1219264.0

Why have you started new thread and didn't mention old one?

[clemahieu]

My understanding is this is an announcement forum.  Is it customary to link every thread that exists about a coin?.

This coin already have 2 threads:
https://bitcointalk.org/index.php?topic=1248759.0
https://bitcointalk.org/index.php?topic=1219264.0

Why have you started new thread and didn't mention old one?

[CjMapope]

well i for one think you met Monsters questions very well
this is a REAL project, a long term working one, looking at the github will tell you that (like 1000 commits and over 1+years of them)
i will be watching this, and have snagged a few from your faucet to hold, thx!

[truerue]

My understanding is this is an announcement forum.  Is it customary to link every thread that exists about a coin?.

This coin already have 2 threads:
https://bitcointalk.org/index.php?topic=1248759.0
https://bitcointalk.org/index.php?topic=1219264.0

Why have you started new thread and didn't mention old one?

Usually devs create only one thread for one coin. If more than one thread necessary they mention that this is old coin and post link to older thread. Otherwise people can think that this is a new coin.

[Bank_sy]

My understanding is this is an announcement forum.  Is it customary to link every thread that exists about a coin?.

This coin already have 2 threads:
https://bitcointalk.org/index.php?topic=1248759.0
https://bitcointalk.org/index.php?topic=1219264.0

Why have you started new thread and didn't mention old one?

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?

[clemahieu]

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?.

This coin already have 2 threads:
https://bitcointalk.org/index.php?topic=1248759.0
https://bitcointalk.org/index.php?topic=1219264.0

Why have you started new thread and didn't mention old one?

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?

[c2m]

@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
 

[clemahieu]

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
 

[c2m]

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!

[clemahieu]

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!

[clemahieu]

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/#/demos

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!

[James_H]

There are people who know how to solve this problem?