There are people who know how to solve this problem?
my suggestion would be make sure run the vc_redist64 that comes with after install of 7.4.3 ;\
you are using 7.4.3 hey?
it looks like a pre-requisite error to me
Topic: RaiBlocks eliminates confirmation delays and fees bringing refreshing simplicity (Read 2788 times)
April 20, 2016, 01:51:27 PM
my suggestion would be make sure run the vc_redist64 that comes with after install of 7.4.3 ;\
you are using 7.4.3 hey?
it looks like a pre-requisite error to me
April 20, 2016, 01:18:36 PM
There are people who know how to solve this problem?
March 03, 2016, 06:34:53 PM
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
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!
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
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!
March 03, 2016, 06:14:04 PM
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.
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!
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
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!
March 03, 2016, 05:44:22 PM
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
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!
March 03, 2016, 04:09:48 PM
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
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
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
March 03, 2016, 03:59:29 PM
@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
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
March 03, 2016, 03:49:01 PM
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.
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?
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://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
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?
March 03, 2016, 03:46:17 PM
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://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
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?
March 03, 2016, 03:41:44 PM
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://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
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.
March 03, 2016, 03:10:14 PM
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!
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!
March 03, 2016, 02:39:51 PM
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://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
March 03, 2016, 02:33:36 PM
This coin already have 2 threads:
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
https://bitcointalksearch.org/topic/ann-raiblocks-712-and-cryptsy-voting-1248759
https://bitcointalksearch.org/topic/block-lattice-1219264
Why have you started new thread and didn't mention old one?
March 03, 2016, 11:45:57 AM
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.
March 03, 2016, 11:41:44 AM
Is it mineable? Any pools in existence?
March 03, 2016, 11:24:56 AM
Looks like Qihoo-360 flags the WinAmp uninstaller for the same thing. 
http://forums.winamp.com/showthread.php?t=388471
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!
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.net
Follow us on Twitter: @raiblocks
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!
March 03, 2016, 11:22:14 AM
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
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
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
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
March 03, 2016, 11:13:54 AM
Feel free to recompile it and always run wallets inside a VM.
I compiled it myself, maybe scan with a reputable scanner?
I compiled it myself, maybe scan with a reputable scanner?
March 03, 2016, 11:08:38 AM
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
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
March 03, 2016, 11:03:42 AM
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
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!
Jump to: