Will we get to see how it works after you're done? 
Hey, you can test it for yourself now!
Topic: [ANN] SpreadCoin | Decentralize Everything (decentralized blockexplorer coming) - page 140. (Read 790391 times)
April 25, 2016, 03:14:25 AM
Hey, you can test it for yourself now!
April 25, 2016, 03:13:13 AM
A better strategy would be to have a dynamic number of servicenodes tied to profitability feasibility. Lets not delude ourselves, servicenodes are of far more important value than miners. If not for servicenodes, what is the point of mining? georgem, lets release a video already!
That's such an upside down way of thinking.
Yes, servicenodes are important, but they will stand on the shoulders of the miners.
April 25, 2016, 03:03:02 AM
Hey everybody,
I created an experimental build of spreadcoin codenamed muscleminer (EX1).
We are testing my proposal regarding how the future servicenode reward percentage will change over time, if miners are allowed to directly influence it through block voting.
The percentage is calculated by taking the average of the votes of the last 1440 blocks.
ATTENTION: Any coins you mine with this build are worthless!
This is just for testing purposes and to prove a concept.
Currently a windows version is available here:
www.spreadcoin.info/downloads/EX1-muscleminer.zip
I added some functionality to the wallet, and adjusted the protocol/blockchain:
That's similar to the CPU Miner you already know.
You can now set your SN percentage vote here, and should you find a block it will write your vote into the blockchain.
It will then calculate the average percentage of the servicenode reward based on the last 1440 votes. (And if there are not enough votes, the rest is considered zero votes).
The average percentage is updated with every new block that is found.
You can check all the recent votes, and observe how the average percentage changes over time.
Maybe you can try and influence it? Please feel free to play around with it.
Mining is easy, so you should find blocks on a per minute basis.
Blockchain has been adjusted so that there is now a new byte before the tx-segment:
Don't freak out about the green theme design, lol.
I created a color patch that allows me to quickly create themes for experimental builds and testnet versions.
This will be helpful in the future.
Also, I want this to be idiot-proof, and this helps!
BTW, you can run this experimental version side by side with your normal spreadcoin wallet if you like.
They run on completely separate ports, datadirs, blockchains, etc..
I will add versions for linux and mac and github source later today.
I have tons of stuff to discuss, but have to look after a few things first.
Stay tuned for more, and let's see where this goes.
I created an experimental build of spreadcoin codenamed muscleminer (EX1).
We are testing my proposal regarding how the future servicenode reward percentage will change over time, if miners are allowed to directly influence it through block voting.
The percentage is calculated by taking the average of the votes of the last 1440 blocks.
ATTENTION: Any coins you mine with this build are worthless!
This is just for testing purposes and to prove a concept.
Currently a windows version is available here:
www.spreadcoin.info/downloads/EX1-muscleminer.zip
I added some functionality to the wallet, and adjusted the protocol/blockchain:
That's similar to the CPU Miner you already know.
You can now set your SN percentage vote here, and should you find a block it will write your vote into the blockchain.
It will then calculate the average percentage of the servicenode reward based on the last 1440 votes. (And if there are not enough votes, the rest is considered zero votes).
The average percentage is updated with every new block that is found.
You can check all the recent votes, and observe how the average percentage changes over time.
Maybe you can try and influence it? Please feel free to play around with it.
Mining is easy, so you should find blocks on a per minute basis.
Blockchain has been adjusted so that there is now a new byte before the tx-segment:
Don't freak out about the green theme design, lol.
I created a color patch that allows me to quickly create themes for experimental builds and testnet versions.
This will be helpful in the future.
Also, I want this to be idiot-proof, and this helps!
BTW, you can run this experimental version side by side with your normal spreadcoin wallet if you like.
They run on completely separate ports, datadirs, blockchains, etc..
I will add versions for linux and mac and github source later today.
I have tons of stuff to discuss, but have to look after a few things first.
Stay tuned for more, and let's see where this goes.
April 24, 2016, 10:34:46 PM
Based on my calculations (highly unscientific) I have determined that Georgem operates in a different realm of existence and thus experiences extreme time dilation. For every hour we experience Georgem experiences less than a third of that. With this in mind, Georgem has been highly accurate with his time predications.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
perfectionists...you love them; and get irritated by them all at the same time.
Hahah I'm sure he's doing a great job. I think it's fun to create backstories for internet friends. You typically don't know much about them and can only infer things based on what they post, their username, etc. it's rather fun to speculate on, even if we never actually find out the "real" story. Envisioning what they look like, what they eat for breakfast, their favorite porno.... Idk. A whole slew of things are more ambiguous because people are difficult to frame based on solely their internet activities.
April 24, 2016, 10:17:27 PM
Based on my calculations (highly unscientific) I have determined that Georgem operates in a different realm of existence and thus experiences extreme time dilation. For every hour we experience Georgem experiences less than a third of that. With this in mind, Georgem has been highly accurate with his time predications.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
perfectionists...you love them; and get irritated by them all at the same time.
April 24, 2016, 05:30:08 PM
Based on my calculations (highly unscientific) I have determined that Georgem operates in a different realm of existence and thus experiences extreme time dilation. For every hour we experience Georgem experiences less than a third of that. With this in mind, Georgem has been highly accurate with his time predications.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
I have not yet figured out the cause of such time dilations. It is entirely possible that Georgem is not in fact from Switzerland and is instead a feral coder from Chernobyl. The long exposure to radiation has made him a master of decentralization but unfortunately has mixed up his time perception.
April 24, 2016, 02:04:33 PM
Finally, here it is:
.........snip....
The general idea is that there is some additional information in each block that proofs that miner knows whole block and private key for spending coinbase transaction. That means that if you mine in a pool you can submit shares as usual and get reward for them but if you will actually find a valid block then you can send it directly to the network instead of the pool and get full reward for it. Pool may detect it and ban you but this is still may be advantageous for you. If your mining power gives you low probability of finding a block then if you will accidentally find a block it gives you more profit even if the pool will ban you for not sharing this block. If you have enough mining power to find blocks consistently then you can connect to a pool and submit shares for some time but steal the first found block, this way you can get both reward for your shares and actual block that you mined, this is like doubling your hashrate.
Given all this I don't expect that anyone will create a pool. But if someone will then I will modify whatever miner software will be used for it to implement the stealing described above, we may expect that most pool miners will then switch to this cheating version which will make this pool useless.
Also I made built-in GUI for the miner. Currently it is still the same CPU miner but in the future I want to make as interface to external miners. Other developers (and me) will be able to independently create CPU and GPU miners and fastest such miners will be distributed with the wallet and available from GUI.
I changed difficulty retarget to six hours. I don't want to set it to lower values because then it may become vulnerable to manipulation by setting improper block timestamps.
Existing GPU miner will become unusable after the fork point because of the modifications to the mining algorithm which are necessary to prevent pools.
.........snip....
The general idea is that there is some additional information in each block that proofs that miner knows whole block and private key for spending coinbase transaction. That means that if you mine in a pool you can submit shares as usual and get reward for them but if you will actually find a valid block then you can send it directly to the network instead of the pool and get full reward for it. Pool may detect it and ban you but this is still may be advantageous for you. If your mining power gives you low probability of finding a block then if you will accidentally find a block it gives you more profit even if the pool will ban you for not sharing this block. If you have enough mining power to find blocks consistently then you can connect to a pool and submit shares for some time but steal the first found block, this way you can get both reward for your shares and actual block that you mined, this is like doubling your hashrate.
Given all this I don't expect that anyone will create a pool. But if someone will then I will modify whatever miner software will be used for it to implement the stealing described above, we may expect that most pool miners will then switch to this cheating version which will make this pool useless.
Also I made built-in GUI for the miner. Currently it is still the same CPU miner but in the future I want to make as interface to external miners. Other developers (and me) will be able to independently create CPU and GPU miners and fastest such miners will be distributed with the wallet and available from GUI.
I changed difficulty retarget to six hours. I don't want to set it to lower values because then it may become vulnerable to manipulation by setting improper block timestamps.
Existing GPU miner will become unusable after the fork point because of the modifications to the mining algorithm which are necessary to prevent pools.
April 24, 2016, 02:01:52 PM
does p2pool work here?
Solo mining is the main focus.
AFAIK, it makes no difference to send the new block to the pool or send it directly to the network, since it doesn't matter who posts it, but ratter who is able to retrieve it.
It is important if both miner and pool knows the private key. Whoever will be first to broadcast the spending transaction to other miners will win.Since the miner must have the PK to mine, it can always spend the money from the pool, even the blocks he did not mine by himself.
Pool can give different private keys to different miners.And if I get that right, to be accepted the block must not only hash to a certain difficulty, but also the generated coins must be sent to the same address that signs the block? So i can't mine directly to more than one address like p2pool does?
Yes. April 24, 2016, 01:57:42 PM
Right now I'm creating an experimental build for testnet that will allow us to CPU-mine and set our vote and observe how the percentage changes over time (1440 votes per day).
Should be fun. I hope to have it finished in a few hours.
Great, let's start. Got some rigs that need a challenge.
Let's get it going, today is a good day for testing
We want to test
We want to test
We want to test
We want to test
We want to test
Etc
April 24, 2016, 12:24:49 PM
does p2pool work here?
April 24, 2016, 03:08:59 AM
(1440 votes per day).
I vaguely remember NXT using this number for confirmations before a block becomes permanently fixed; sorry to go a bit off-topic but what is the mathematical significance of this number?
Maybe it has something to do with minutes per day. 24h*60min=1440min
So if you have block time 1 minute You have 1440 blocks(and votes) per day.
April 23, 2016, 08:55:23 PM
people don't even need a recommendation anymore to figure out the best percentage.
Does the introduction of voting means that the current SpreadX11 format will change? Will there be backwards compatibility (i.e. will older miner programs work) or will this be a hard fork on all levels?Practically nothing will change.
It's just an additional byte in the blockheader that miners have to set (and full nodes will expect), and it will have a default value preset for miners who don't care.
But the value will have to be there, because blocks without this byte will be considered invalid (since their header has a different length). So this will be a new protocol version and will require a fork.
Should be very easy to adjust mining software since SpreadX11 (both the X11-part and the Spread anti-pool-mechanism-part) stay exactly the same, just a new byte has to be introduced, and somekind of GUI or CMD input read in so that miners can type in or set their vote. (Or simply let them write in their vote in the conf file, and it will be used from then on.)
Right now I'm creating an experimental build for testnet that will allow us to CPU-mine and set our vote and observe how the percentage changes over time (1440 votes per day).
Should be fun. I hope to have it finished in a few hours.
Excellent news. Looking forward to this, georgem
April 23, 2016, 05:01:38 PM
Wait, is this the testnet? 
April 23, 2016, 04:49:17 PM
people don't even need a recommendation anymore to figure out the best percentage.
Does the introduction of voting means that the current SpreadX11 format will change? Will there be backwards compatibility (i.e. will older miner programs work) or will this be a hard fork on all levels?Practically nothing will change.
It's just an additional byte in the blockheader that miners have to set (and full nodes will expect), and it will have a default value preset for miners who don't care.
But the value will have to be there, because blocks without this byte will be considered invalid (since their header has a different length). So this will be a new protocol version and will require a fork.
Should be very easy to adjust mining software since SpreadX11 (both the X11-part and the Spread anti-pool-mechanism-part) stay exactly the same, just a new byte has to be introduced, and somekind of GUI or CMD input read in so that miners can type in or set their vote. (Or simply let them write in their vote in the conf file, and it will be used from then on.)
Right now I'm creating an experimental build for testnet that will allow us to CPU-mine and set our vote and observe how the percentage changes over time (1440 votes per day).
Should be fun. I hope to have it finished in a few hours.
Great, let's start. Got some rigs that need a challenge.
April 23, 2016, 04:43:43 PM
(1440 votes per day).
I vaguely remember NXT using this number for confirmations before a block becomes permanently fixed; sorry to go a bit off-topic but what is the mathematical significance of this number?
April 23, 2016, 01:07:13 PM
people don't even need a recommendation anymore to figure out the best percentage.
Does the introduction of voting means that the current SpreadX11 format will change? Will there be backwards compatibility (i.e. will older miner programs work) or will this be a hard fork on all levels?Practically nothing will change.
It's just an additional byte in the blockheader that miners have to set (and full nodes will expect), and it will have a default value preset for miners who don't care.
But the value will have to be there, because blocks without this byte will be considered invalid (since their header has a different length). So this will be a new protocol version and will require a fork.
Should be very easy to adjust mining software since SpreadX11 (both the X11-part and the Spread anti-pool-mechanism-part) stay exactly the same, just a new byte has to be introduced, and somekind of GUI or CMD input read in so that miners can type in or set their vote. (Or simply let them write in their vote in the conf file, and it will be used from then on.)
Right now I'm creating an experimental build for testnet that will allow us to CPU-mine and set our vote and observe how the percentage changes over time (1440 votes per day).
Should be fun. I hope to have it finished in a few hours.
Will we get to see how it works after you're done?
April 23, 2016, 10:51:24 AM
people don't even need a recommendation anymore to figure out the best percentage.
Does the introduction of voting means that the current SpreadX11 format will change? Will there be backwards compatibility (i.e. will older miner programs work) or will this be a hard fork on all levels?Practically nothing will change.
It's just an additional byte in the blockheader that miners have to set (and full nodes will expect), and it will have a default value preset for miners who don't care.
But the value will have to be there, because blocks without this byte will be considered invalid (since their header has a different length). So this will be a new protocol version and will require a fork.
Should be very easy to adjust mining software since SpreadX11 (both the X11-part and the Spread anti-pool-mechanism-part) stay exactly the same, just a new byte has to be introduced, and somekind of GUI or CMD input read in so that miners can type in or set their vote. (Or simply let them write in their vote in the conf file, and it will be used from then on.)
Right now I'm creating an experimental build for testnet that will allow us to CPU-mine and set our vote and observe how the percentage changes over time (1440 votes per day).
Should be fun. I hope to have it finished in a few hours.
April 23, 2016, 06:05:51 AM
A better strategy would be to have a dynamic number of servicenodes tied to profitability feasibility. Lets not delude ourselves, servicenodes are of far more important value than miners. If not for servicenodes, what is the point of mining? georgem, lets release a video already!
April 22, 2016, 02:12:53 PM
Any chance we can get a video of progress so I can put it up on online for promo efforts?
April 20, 2016, 11:24:30 PM
Can anybody put some light on these:
1. All (1440) elected nodes get payments when/how/in what order?
2. If my node gets elected and is on borderline how long before I receive
a payment? If my node gets "un-elected" before 24h are through,
what are the chances that I will still get paid? Or the new node will be paid instead?
That is a good sum up of my proposal earlier:
which on second thought is not that good, because it means
the burden of service node fee collection will only fall on all "miner-only participants".
Basically my idea was to incentivize miners to run a service node too.
As for the 20% - I have no clue...
1. All (1440) elected nodes get payments when/how/in what order?
2. If my node gets elected and is on borderline how long before I receive
a payment? If my node gets "un-elected" before 24h are through,
what are the chances that I will still get paid? Or the new node will be paid instead?
That is a good sum up of my proposal earlier:
...
You are saying that in the case that a miner has a service node, they will vote for the reward, but will not pay the reward because they have a node...
...
But your last question becomes the problem - who determines that "proper percentage."
You are saying that in the case that a miner has a service node, they will vote for the reward, but will not pay the reward because they have a node...
...
But your last question becomes the problem - who determines that "proper percentage."
which on second thought is not that good, because it means
the burden of service node fee collection will only fall on all "miner-only participants".
Basically my idea was to incentivize miners to run a service node too.
As for the 20% - I have no clue...
Jump to: