Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 271. (Read 790391 times)
June 27, 2015, 12:12:12 PM
Another reason to fork to Bitcoin core.
Good job chaositec is on that one.
What's the bounty at now?
June 27, 2015, 08:42:20 AM
Interesting bitcoin core ddos fix
https://www.mail-archive.com/[email protected]/msg00216.html
https://www.mail-archive.com/[email protected]/msg00216.html
June 27, 2015, 07:17:33 AM
Seems to be some agreement that PR will only start once we have bitcoin nodes up on testnet.
Any other thoughts?
Any other thoughts?
June 26, 2015, 04:04:20 PM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
Re the payment structure.
Servicenodes would be profitable now, with 30% blockreward.
Other payment mechanisms can be brought to the table later on.
I advocate a 30% reward (from miners) for servicenodes and an arbitrary % of the fee from each transaction via the servicenode network.
Payouts would organically grow with more use of the SN network, and with that said maybe sometime in the future the block reward can be lowered.
I like the idea of a small cut of transaction fees but for some reason it sets alarm bells off in my head. I can't put my finger on it. Maybe I've been hanging around with BTC people too much
I understand lol
I'm thinking along the lines of... Nothing is free, things cost money.
A 0.1% fee on the size of transaction for using the "escrow" feature say, is that wrong? If someone doesn't like 0.1% fee they can use another provider.
Unless you can make all of this free, but still have incentive for people wanting to join the SN gang.
I think its a good way to create a market.
June 26, 2015, 03:54:29 PM
I can fit 10 daemons comfortably on a 2GB server with a low end CPU. I'm talking about *coind, not *coin-qt. Maybe you'd need 3 64GB servers... point is it aint much.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
Yes coind, that's why I repeatedly said "daemons".
You can maybe put 10 "idle" daemons on a 4 GB server, but the moment they actually need to do some work (verifying, etc) they will totally crash the system.
Hey, everybody is invited to back up his claims, I will post a few screenshots later of the CPU and RAM load. (starting up, synching process and idle)
During validation / verification process when a new block has to be checked I have repeatedly seen CPU spike to 100%, because this is a process that gets high priority by the system, because it needs to be done fast so as to be ready for the next block.
And bitcoin nodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
We can insist the server use a IPv4 address.
I agree that this is a problem that has to be solved: how to discourage the running of multiple nodes on 1 server.
and SPR's service needs to be competitive.
I do agree.
Other coins could replicate servicenodes, offer the exact same - the PoBN, meaning running a server would be cheaper and more profitable.
Maybe other coins would mimic servicenodes and keep PoBN? If the dev team can pull this off the potential is pretty good, imo.
Maybe other coins would want to jump on the band wagon and add another 500 Randomcoinnodes/bitcoinnodes and gain support by supporting the bitcoin network.
Also, it's irrelevant how easy or hard it is to set up 1000 bitcoin nodes, the fact is there are only 6000 bitcoin nodes worldwide. People just aren't building servers and hosting 1000 nodes, no matter how easy it is, it's just not happening. There isn't a direct financial incentive, so i understand. The thing is SPR can make it financially viable (if successful). It's an interesting proposition with alot of potential.
Like you said tho, SPR still needs to remain competitive.
June 26, 2015, 12:40:59 PM
I can fit 10 daemons comfortably on a 2GB server with a low end CPU. I'm talking about *coind, not *coin-qt. Maybe you'd need 3 64GB servers... point is it aint much.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
Yes coind, that's why I repeatedly said "daemons".
You can maybe put 10 "idle" daemons on a 4 GB server, but the moment they actually need to do some work (verifying, etc) they will totally crash the system.
Hey, everybody is invited to back up his claims, I will post a few screenshots later of the CPU and RAM load. (starting up, synching process and idle)
During validation / verification process when a new block has to be checked I have repeatedly seen CPU spike to 100%, because this is a process that gets high priority by the system, because it needs to be done fast so as to be ready for the next block.
And bitcoin nodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
We can insist the server use a IPv4 address.
I agree that this is a problem that has to be solved: how to discourage the running of multiple nodes on 1 server.
Next time try starting and syncing them one at a time, or use a bootstrap blockchain file. My BCR and DASH daemons never go over 150MB, usually they hover around 110-120MB while running. Bitcoind does a whole lot less so probably uses even less RAM.
You can put whatever restrictions on SPR nodes you like, it doesn't change the fact that running a crapload of BTC nodes is neither difficult nor expensive, and SPR's service needs to be competitive. Forcing SPR node ops to buy IPv4 addresses just adds to their costs.
June 26, 2015, 12:06:52 PM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
Re the payment structure.
Servicenodes would be profitable now, with 30% blockreward.
Other payment mechanisms can be brought to the table later on.
I advocate a 30% reward (from miners) for servicenodes and an arbitrary % of the fee from each transaction via the servicenode network.
Payouts would organically grow with more use of the SN network, and with that said maybe sometime in the future the block reward can be lowered.
I like the idea of a small cut of transaction fees but for some reason it sets alarm bells off in my head. I can't put my finger on it. Maybe I've been hanging around with BTC people too much
June 26, 2015, 11:27:40 AM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
Re the payment structure.
Servicenodes would be profitable now, with 30% blockreward.
Other payment mechanisms can be brought to the table later on.
I advocate a 30% reward (from miners) for servicenodes and an arbitrary % of the fee from each transaction via the servicenode network.
Payouts would organically grow with more use of the SN network, and with that said maybe sometime in the future the block reward can be lowered.
June 26, 2015, 11:06:49 AM
Having the ability to run a full bitcoin node side by side with a servicenode will open the door for many more future services,
helping the bitcoin network is merely the first obvious one.
helping the bitcoin network is merely the first obvious one.
Reserved, for that annoying pic saying: shut up and take my money
June 26, 2015, 10:55:54 AM
I can fit 10 daemons comfortably on a 2GB server with a low end CPU. I'm talking about *coind, not *coin-qt. Maybe you'd need 3 64GB servers... point is it aint much.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
And bitcoin bodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
Yes coind, that's why I repeatedly said "daemons".
You can maybe put 10 "idle" daemons on a 4 GB server, but the moment they actually need to do some work (verifying, etc) they will totally crash the system.
Hey, everybody is invited to back up his claims, I will post a few screenshots later of the CPU and RAM load. (starting up, synching process and idle)
During validation / verification process when a new block has to be checked I have repeatedly seen CPU spike to 100%, because this is a process that gets high priority by the system, because it needs to be done fast so as to be ready for the next block.
And bitcoin nodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
We can insist the server use a IPv4 address.
I agree that this is a problem that has to be solved: how to discourage the running of multiple nodes on 1 server.
June 26, 2015, 10:50:00 AM
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, ...
If SPR node ops can run a thousand BTC nodes for a few $ a month each, so could BTC zealots,...
I tried installing as many daemons as possible on a 24 GB RAM server a few months ago.
I was only able to start about 15-20 of them before running out of RAM.
(And most of those daemons were for small altcoins that didn't have the high verification needs of BTC (lots of CPU))
1000 daemons on 2 servers is not possible, you need to spread this over a few dozen servers, plus it will probably cost you a few thousand dollars a month.
Also, with SPR we will have the requirement that every node needs to run on a unique IP.
So having enough servers to be able to run 1000 daemons is one thing, but having unique IPs for every single daemon will cost you a fortune. Every month.
I can fit 10 daemons comfortably on a 2GB server with a low end CPU. I'm talking about *coind, not *coin-qt. Maybe you'd need 3 64GB servers... point is it aint much.
And bitcoin nodes can be run on IPv6 addresses, either directly or via a tunnel. IPv6 addresses are practically free.
June 26, 2015, 10:43:31 AM
Having the ability to run a full bitcoin node side by side with a servicenode will open the door for many more future services,
helping the bitcoin network is merely the first obvious one.
helping the bitcoin network is merely the first obvious one.
June 26, 2015, 10:40:21 AM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
I guess the next step after the final version of the QT is released should be the roadmap for servicenode testing...
Agreed. I will have the release version ready probably by monday.
June 26, 2015, 10:36:25 AM
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, ...
If SPR node ops can run a thousand BTC nodes for a few $ a month each, so could BTC zealots,...
I tried installing as many daemons as possible on a 24 GB RAM server a few months ago.
I was only able to start about 15-20 of them before running out of RAM.
(And most of those daemons were for small altcoins that didn't have the high verification needs of BTC (lots of CPU, often up to 100% during synching))
1000 daemons on 2 servers is not possible, you need to spread this over a few dozen servers, plus it will probably cost you a few thousand dollars a month.
Also, with SPR we will have the requirement that every node needs to run on a unique IP.
So having enough servers to be able to run 1000 daemons is one thing, but having unique IPs for every single daemon will cost you a fortune. Every month.
June 26, 2015, 10:25:32 AM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
I guess the next step after the final version of the QT is released should be the roadmap for servicenode testing...
June 26, 2015, 10:10:21 AM
Looks like we've passed the Crouton test.
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
@devs when can we start scheduling the allocation of mining rewards to node owners?
Obviously we need some nodes up on mainnet, but we might as well signal the reallocation to the miners while there are so few to complian
June 26, 2015, 09:43:30 AM
....
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, you can buy this stuff for peanuts on ebay...
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, you can buy this stuff for peanuts on ebay...
We need to test that this is a valid option. If it is, then Bitcoin has no problems.
But, Bitcoin does have problems. So it can't be that easy, or cost efficient. Bandwidth costs alone would make it expensive to set-up and maintain.
Bitcoin has plenty of problems.
If SPR node ops can run a thousand BTC nodes for a few $ a month each, so could BTC zealots, they're just too tightfisted, and the Bitcoin Foundation would rather spend their money flying themselves around the world to fancy conferences where they can all dip their beards in free soup.
June 26, 2015, 09:33:55 AM
....
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, you can buy this stuff for peanuts on ebay...
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, you can buy this stuff for peanuts on ebay...
We need to test that this is a valid option. If it is, then Bitcoin has no problems.
But, Bitcoin does have problems. So it can't be that easy, or cost efficient. Bandwidth costs alone would make it expensive to set-up and maintain.
June 26, 2015, 09:31:08 AM
...SPR nodes could compete on cost I suppose if their operation is subsidised anyway by other reward structures.
+101
An incentives program can't generate super profits, because it would encourage ASIC style industrial farms.
Just enough profit to encourage lots of people to get involved. Going back to a model similar to USB antminers, maybe.
The value is then in the price and the amount of data that can be mined.
June 26, 2015, 09:22:26 AM
Exactly.
Can a company run Full Bitcoin nodes in the range of 1,000 to 5,000 nodes, around the world? Doubt it. Google, Apple, Microsoft, sure. But can they beat SPR's decentralized model in terms of no trust required? A community of thousands can match any big company or government. Dash has proven this already.
If you are looking for data, which would you prefer, a company making a profit with a small number of nodes, or a public service project that has many thousands of nodes?
Scripts / APIs are relatively easy. I've allowed for a bounty in the revenue streams to pay for requested scripts, all open source so they can be vetted.
Can a company run Full Bitcoin nodes in the range of 1,000 to 5,000 nodes, around the world? Doubt it. Google, Apple, Microsoft, sure. But can they beat SPR's decentralized model in terms of no trust required? A community of thousands can match any big company or government. Dash has proven this already.
If you are looking for data, which would you prefer, a company making a profit with a small number of nodes, or a public service project that has many thousands of nodes?
Scripts / APIs are relatively easy. I've allowed for a bounty in the revenue streams to pay for requested scripts, all open source so they can be vetted.
Two servers with 64GB RAM each and a few TB of storage can easily run a thousand full BTC nodes. This isn't a big expense, you can buy this stuff for peanuts on ebay. Physical location is irrelevant unless a few milliseconds of latency is critical to you, and if it is then you just set up your servers 'next door' in network terms to your target(s).
Or, alternatively, if a bunch of SPR enthusiasts can rent a bunch of VPS instances, anyone can.
I'm not being obnoxious for the sake of it here, I'm just trying to pin down the value proposition of data mining via SPR nodes vs. Inquisitive Inc. doing it themselves or using another provider.
I don't see any intrinsic difference in trust between using any one outsorced data mining provider vs. any other.
SPR nodes could compete on cost I suppose if their operation is subsidised anyway by other reward structures.
Jump to: