Topic: [ANN][XRB]Cryptocurrency's killer app: RaiBlocks micropayments - page 580. (Read 775281 times)
April 16, 2016, 04:19:15 AM
not able to send MRAI , any idea why ? When I give the address and amount and click send button , send button goes blur and nothing happens , My wallet is synced correctly.
April 16, 2016, 04:12:38 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
spam? are you complaining about your own lack of diligence.
this is most fair distribution I have ever seen
First,You should go to join School to learn English. (Ching chang chu won't work here)
What i meant with spam is Only few people using this Raiblocks and they hiring workers.In that way Few people getting more than 20k from the faucets.That way more mrai from people who working on their own.
Fair distribution means a b c will get same amount.People that got hired will never be asset of this.
You guys could let them known what is raiblocks and ask them to use mrai Instead of hiring them to spam the faucet.
first of all, You are the man trying to spam many ppl here.
playing around not keeping your own words. (don you want me to paste your cheating records?)
your fluent English won't make you suck your own dick better.
April 16, 2016, 04:12:19 AM
I think you dint understand what he told . He said people are hiring others to work for them , So most of the coins belongs to a few people, now is it fair according to you ?
Those people would sell it anyways! And many decide to keep some for themselves!
You can't stop people like me from accumulating. And I don't understand what your problem with that is.
April 16, 2016, 04:11:01 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
spam? are you complaining about your own lack of diligence.
this is most fair distribution I have ever seen
I think you dint understand what he told . He said people are hiring others to work for them , So most of the coins belongs to a few people, now is it fair according to you ?
April 16, 2016, 04:02:31 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
spam? are you complaining about your own lack of diligence.
this is most fair distribution I have ever seen
First,You should go to join School to learn English. (Ching chang chu won't work here)
What i meant with spam is Only few people using this Raiblocks and they hiring workers.In that way Few people getting more than 20k from the faucets.That way more mrai from people who working on their own.
Fair distribution means a b c will get same amount.People that got hired will never be asset of this.
You guys could let them known what is raiblocks and ask them to use mrai Instead of hiring them to spam the faucet.
April 16, 2016, 03:56:56 AM
definlty failing due to fast decrease of value, i bet is the Asians indians hiring puppets
Decrease of value?
April 16, 2016, 03:55:16 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
definlty failing due to fast decrease of value, i bet is the Asians indians hiring puppets
April 16, 2016, 03:50:26 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
spam? are you complaining about your own lack of diligence.
this is most fair distribution I have ever seen
April 16, 2016, 03:39:50 AM
And "just" 100 people. Imagine what happen if 1000 people or 10 000 people use it... 1Mrai become a very high value.
Well, that's assuming it can scale. But I think it would have to go through a few more growing pains before it can handle bigger number of transactions.
April 16, 2016, 03:26:51 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Are you confusing "equal distribution" with "fair distribution"? What is fair to you?
It's a free market, you can't stop people from selling it, and you can't stop people from buying it. That's FAIR!
If you look at my spreadsheet, I've only accumulated 22,000 Mrai through hiring people in 2 days. Which is NOTHING compared to what the faucet generates. It's also interest in mining it.
If there are 100 people mining 210 captchas per hour, that's 21,000 Mrai per hour. So it ONLY takes 100 people to drop it down to 1 Mrai / captcha.
April 16, 2016, 03:16:27 AM
Now its decrease to under 4 per claim.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
Some people Spamming the service section for abusing faucets,What rail devs thinks about it?I think it's not a fair distribution.
April 16, 2016, 02:04:59 AM
What you're noticing is precaching the PoW for your next transaction. I designed the PoW so it uses information from your previous transaction so in the usual case you can fire off 1 transaction instantly and the work generation latency gets hidden in the time until your next transaction.
Part of this will be helped with the OpenCL module I'm putting together for people who need to handle higher transaction loads.
Part of this will be helped with the OpenCL module I'm putting together for people who need to handle higher transaction loads.
I have no problem with the PoW. I DO have a problem with it blocking vital operations such as the RPC calls.
April 16, 2016, 02:04:15 AM
How to compete spam without fees?
There is a small Proof of Work per transaction. That may need to be able to adjust dynamically though. And also the proof of work should be on the sender, but not on the receiver. I still don't understand why receiver has to do PoW.
April 16, 2016, 02:03:45 AM
How to compete spam without fees?
A small hashcash style proof of work.
April 16, 2016, 02:03:07 AM
Yea that sound like a suspect, the PoW that's used to prevent transaction spam. Are you running it inside a VM? Possible 1 CPU core? In your config.json what does it list for work_thread and io_thread count?
The PoW in the transaction makes sense, but I'm not sure why it's needed at address generation time.
By the way - trying to create addresses via the RPC does not appear to be functional. (Something an exchange will likely need)
Got 8 threads - again it's not that long of a time it's down. It's workable. But I imagine an exchange would need to handle at least 100 times more transactions.
What you're noticing is precaching the PoW for your next transaction. I designed the PoW so it uses information from your previous transaction so in the usual case you can fire off 1 transaction instantly and the work generation latency gets hidden in the time until your next transaction.
Part of this will be helped with the OpenCL module I'm putting together for people who need to handle higher transaction loads.
April 16, 2016, 02:02:06 AM
How to compete spam without fees?
April 16, 2016, 01:56:11 AM
I'm working on cleaning up the build process this weekend, we have a semi lead that I'll be trying to make happen as much as I can. I know a trade thread is an awkward way to do this so I know everyone wants it to happen.
good news in here
I hope everything will be good. April 16, 2016, 01:55:18 AM
Yea that sound like a suspect, the PoW that's used to prevent transaction spam. Are you running it inside a VM? Possible 1 CPU core? In your config.json what does it list for work_thread and io_thread count?
The PoW in the transaction makes sense, but I'm not sure why it's needed at address generation time.
By the way - trying to create addresses via the RPC does not appear to be functional. (Something an exchange will likely need)
Got 8 threads - again it's not that long of a time it's down. It's workable. But I imagine an exchange would need to handle at least 100 times more transactions.
April 16, 2016, 01:48:58 AM
Interesting. Thinking about it I suspect the GUI may not handle that many addresses that well though of course an exchange would use a headless node.
Do you notice slowness during any particular action?
Do you notice slowness during any particular action?
Nothing that is unworkable. But here are a few notes:
- Slowness happens when generating the addresses, and CPU usage goes up / fans start up, etc.
- Slowness also occurs when it is the end of the 2 hours distribution period and balances are being processed
- During that "processing" period (probably in another thread) I also get unresponsiveness, such as:
- transfers go on hold until processing is done
- RPC commands are just blocked until processing is done
- quitting the GUI just "hangs" until processing is done
I'm just thinking if I was an exchange, I'd need a receive address per account, so I'd have to have them pre-generated, or generate on the fly. Either way, it seems generating an address requires some CPU power by itself. (Does it have some PoW associated with it, to prevent address spam?)
Yea that sound like a suspect, the PoW that's used to prevent transaction spam. Are you running it inside a VM? Possible 1 CPU core? In your config.json what does it list for work_thread and io_thread count?
April 16, 2016, 01:30:50 AM
Interesting. Thinking about it I suspect the GUI may not handle that many addresses that well though of course an exchange would use a headless node.
Do you notice slowness during any particular action?
Do you notice slowness during any particular action?
Nothing that is unworkable. But here are a few notes:
- Slowness happens when generating the addresses, and CPU usage goes up / fans start up, etc.
- Slowness also occurs when it is the end of the 2 hours distribution period and balances are being processed
- During that "processing" period (probably in another thread) I also get unresponsiveness, such as:
- transfers go on hold until processing is done
- RPC commands are just blocked until processing is done
- quitting the GUI just "hangs" until processing is done
I'm just thinking if I was an exchange, I'd need a receive address per account, so I'd have to have them pre-generated, or generate on the fly. Either way, it seems generating an address requires some CPU power by itself. (Does it have some PoW associated with it, to prevent address spam?)
Jump to: