Technical Solution Proposals
-
[quote name=“wrapper0feather” post=“21750” timestamp=“1374012886”]
Make the Wallet client have to do a small amount of mining, if you increase your wallet from minimum mining you get paid part of transaction fees (to wallet).You can choose to be not to do minimum mining if you are on a mobile phone.
If you choose to wallet mine, you can become a node, and are paid out a block fee. We could add % payment of transaction fee to a wallet nodes, or you can join a pool.
[/quote]Wouldn’t work. Difficulty is too high for solo mining, most wallets trying will never find a block. Unless, that is, if you had a second blockchain with a low difficulty. But I’m not sure what the point of that would be, since you may as well just put your coins on the second block chain instead of the first.
[quote]
Change the confirm algorithm, such that an extra 100% of miners have to be confirmed by wallets doing micro confirms. After implementation we could increase the confirms or make the them exponential i.e. early confirms have more weight, depending on the requirement, later confirms have less weight, but there are more of them. This would fight early, danger of attack, but could be adjusted for the later, need for faster confirms.This reduces attack risk by increasing complexity and size of attack required.
[/quote]The PoW model is potent because blocks are TRIVIAL to verify, yet difficult to produce. This suggestion breaks the client wallet model badly. 0% of the miners need to verify the transaction for it to be valid, but 100% of them have to reject it if it’s invalid for it to NOT be included. You have the model backwards. PoW NEEDS to be trivial to verify, yet hard to create.
-
Is it worth putting any technical solutions up for consideration? There doesn’t seem an enabling mechanism for them to be developed to workable solutions.
-
[quote name=“wrapper0feather” post=“24065” timestamp=“1375406396”]
Is it worth putting any technical solutions up for consideration? There doesn’t seem an enabling mechanism for them to be developed to workable solutions.
[/quote]Sure there is! Feathercoin is open source software. Anyone with a good idea can come along, implement it, and ask for the community’s acceptance. What’s lacking is the enabling mechanism for them to be organized by the community and voted upon. Bitcoin has BIP, perhaps we should adopt a similar mechanism for tracking proposals and having them accepted by the community for implementation by developers? FIP?
-
Here is the latest Feathercoin Block production chart for July 2013 + 1st Day of August
It shows Actual Block production per Day (Green)
The Block production that should have happened i.e. to Spec (Blue)
The average production for July, + First Day of August. (Dark Green)
The average block production per week. (Purple)
The daily block / Difficulty reading is taken at 19:00 Block Time.
Yellow is the accumulated month average to give an idea of the damping factor.
[attachment deleted by admin]
-
[quote name=“Kevlar” post=“24077” timestamp=“1375416165”]
Sure there is! Feathercoin is open source software. Anyone with a good idea can come along, implement it, and ask for the community’s acceptance. What’s lacking is the enabling mechanism for them to be organized by the community and voted upon. Bitcoin has BIP, perhaps we should adopt a similar mechanism for tracking proposals and having them accepted by the community for implementation by developers? FIP?
[/quote]Yes, I agree, Kevlar, that is a very positive proposal. I’ll look into what BIP / FIP is as well.
I know there is a problem that there is too much for devs to do. But we don’t want to waste ideas and community, when that is a Feathercoins distinguishing feature.
-
This process has been very effective for a number of open source projects. Java and OpenStack come to mind.
Here’s BIP 0001: https://github.com/genjix/bips/blob/master/bip-0001.md
Something similar for FTC would allow the community to formalize and prioritize exactly what it is that’s being worked on, as well as distribute ownership instead of relying on a single developer and their walled garden of vision. The community can migrate new ideas into proposal revisions, priorities can be voted upon, bounties could be raised for implementations, progress for specific proposals can be tracked, and the development process can be made completely transparent and community driven.
-
I’m going to look at updating the code. I’ve done a bit of hacking in various languages, and since I retired I being doing some research on Java, Github and started to look at Python.
My main area (before I stopped working 10 years ago) are, Software specification, management, quality control and research. So Github is new to me, Its a great way to develop, for community inclusion.
What about a permanent Feathercoin thread on CODE. I’ve been keeping an eye on Githum and I see they just found a Bitcoin reference in the Litecoin code…
In that case, we could look at the changes, an give some opinions on how good the change was, wither we should patch it to Feathecoin straight away. Remember, we should be in the software repositories soon so can be auto updated on the important Linux systems (he he)
We could also laugh / learn from other code implementations from other coins. It would be the Ultra Nerd corner?
I’m not saying my code changes would be worth uploading, but, I’m sure other people would be interested in reading areas of interest, and judge better the level of change?
I’ve seen a good thread on Bitcoin where someone has done a description of the functions available. I’ve found it very interesting looking at the debug window,getpeerinfo for instance.
-
I have been looking through the Satoshi functional specification and have found that the change to insist on 1 real transaction would be very easy to make.
I have also noted this slight damping of block production when there are no transactions will be entirely compensated by a reduction of the difficulty when more transactions come through. In addition, it makes attacks more difficult, prevents high hash rates being paid (excessively) for nothing, they must wait for a transaction.
All that needs to happen is that the block will have transactions > 1 to add to the transaction pool instead of transactions greater > 0 currently.
If a miner has not updated the software and added a invalid block, it could be marked as orphan.
I’m not saying the idea doesn’t need development, I don’t know what happens if an attacker could add invalid blocks currently.
>>>>>>>>>>>>>>>>>>>
https://en.bitcoin.it/wiki/Protocol_rules#Difficulty_change
Transactions
There are two collections of transactions:
transaction pool
an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactionsorphan transactions
transactions that can’t go into the pool due to one or more missing input transactions -
This is my last proposal to deal with the current “problems” we have creating a fair, secure and open Feathercoin network.
The improvement in block rate performance of Feathercoin in July over June 2013 has shown how effective, the relatively crude, imposition of 40% difficulty change has been. Although it has not fully corrected the block rate or prevented attacks or Difficulty manipulation by Hash power switching, it has damped the effect of these down considerably.
At the current version of the Feathercoin the Difficulty is calculated on the time stamps and number of Blocks of 500 or so blocks.
I am therefore sugesting that , in Addition, the average of 1000 and 100 block also be taken into account when calculating the difficulty. They could have half the influence or the differnce between the 3 avarages could affect difficulty, with only minor change to the algoryth.
The average over 1000 blocks will give a slight nudge to the block rate to compensate for the current block rate shortfall.
The 100 average will help aleviate against short term high hash miners artificially affecting the market by damping short term influence.
The idea is based on some research I supervised at Manchester University with one of my PhD students Bob Willets in the 1990’s, where we designed an automatic sensor warning / alarm setting system, based on A.I. or self aligning techniques. The funny thing was it worked really well, even when some of the equations were non optimal (wrong)., thus showing me the power of self aligning…
-
Wrapper, difficulty control can be improved significantly with time stamp variation allowance reduced. There are many ways to work around difficulty traps. As I’ve mentioned it earlier today,
[quote]A possible solution is to retarget every 12 blocks (30 minutes) while keeping to calculate new difficulty on the past 504 blocks. It makes difficulty transitions smooth enough without running into other issues.[/quote]
http://forum.feathercoin.com/index.php?topic=2259.msg24323#msg24323
-
Hi Ghostlander,
My analysis of the block production variation shows adding a 14 day average to the difficulty would be more beneficial than a 30 minute average. The problem is short term manipulation and failure to meet long term block averages, both of which are addressed by a longer average.
My previous work in data fusion techniques shows the system will be suitably self aligning as long as the scales of the controlling mechanism are within orders of magnitude of the variation in process to be damped. i.e. they don’t have to be exact, just close.
It is very interesting to note that the 44% restriction in Feathercoin difficulty adjustment has already acted to damp the system, even though that system is made up of a set complex human interaction, and that a 40 % change block difficulty adjustment is a very crude, blunt, damping instrument! The equivalent of a pendulum bashing each side as it swings.
-
[quote name=“wrapper0feather” post=“24641” timestamp=“1375786275”]
Hi Ghostlander,My analysis of the block production variation shows adding a 14 day average to the difficulty would be more beneficial than a 30 minute average. The problem is short term manipulation and failure to meet long term block averages, both of which are addressed by a longer average.
[/quote]The average offered isn’t 30 minutes. It’s 21 hour, no change there. It’s very unproductive to set it at 2 weeks.
-
[quote name=“Kevlar” post=“24056” timestamp=“1375398597”]
[quote author=wrapper0feather link=topic=1478.msg21750#msg21750 date=1374012886]
Make the Wallet client have to do a small amount of mining, if you increase your wallet from minimum mining you get paid part of transaction fees (to wallet).You can choose to be not to do minimum mining if you are on a mobile phone.
If you choose to wallet mine, you can become a node, and are paid out a block fee. We could add % payment of transaction fee to a wallet nodes, or you can join a pool.
[/quote]Wouldn’t work. Difficulty is too high for solo mining, most wallets trying will never find a block. Unless, that is, if you had a second blockchain with a low difficulty. But I’m not sure what the point of that would be, since you may as well just put your coins on the second block chain instead of the first.
invalid for it to NOT be included. You have the model backwards. PoW NEEDS to be trivial to verify, yet hard to create.
[/quote]Why solo mining ? Let the client every time it starts choose a random pool to mine by inserting a list of known pools which are able to offer low difficulty per share into the source. If client chooses to mine against a pool, just use this pool and if he chooses solo mining there is still this “1% of resource mining” against a pool from the list.
Recommend on the feathercoin.com page only using the standard client with maybe some addons like armory or something so people most likely use this one if somebody creates another client except the one from the community…
-
[quote name=“ghostlander” post=“24659” timestamp=“1375792445”]
[quote author=wrapper0feather link=topic=1478.msg24641#msg24641 date=1375786275]
Hi Ghostlander,My analysis of the block production variation shows adding a 14 day average to the difficulty would be more beneficial than a 30 minute average. The problem is short term manipulation and failure to meet long term block averages, both of which are addressed by a longer average.
[/quote]
[quote]
The average offered isn’t 30 minutes. It’s 21 hour, no change there. It’s very unproductive to set it at 2 weeks.
[/quote]Can you explain further what you mean by being unproductive to have an additional block average term for 2 weeks?
Did you read my proposal to have a combined average over short, medium and long term time scales? eg 100, 1000, 10,000 blocks? It is not a change from 574 blocks difficulty calculation average to 8,000 blocks?
So the new way to to calculate difficulty = ((average over 100 + average over 1000 + average over 10,000) / 3)
At the moment Feathercoin is suffering from a long term block production short fall. It is constant miners like me, who are subsidising the shortfall. It is high hash miner coming in at low difficulty then leaving that have been getting all the over produced coins.
I have added my latest chart showing how my 2 week prediction is now coming true for August, as the over block production is now started going into deficit, see yellow line.
[attachment deleted by admin]
-
[quote name=“wrapper0feather” post=“25207” timestamp=“1376210824”]
[quote]
The average offered isn’t 30 minutes. It’s 21 hour, no change there. It’s very unproductive to set it at 2 weeks.
[/quote]Can you explain further what you mean by being unproductive to have an additional block average term for 2 weeks?
Did you read my proposal to have a combined average over short, medium and long term time scales? eg 100, 1000, 10,000 blocks? It is not a change from 574 blocks difficulty calculation average to 8,000 blocks?
So the new way to to calculate difficulty = ((average over 100 + average over 1000 + average over 10,000) / 3)
At the moment Feathercoin is suffering from a long term block production short fall. It is constant miners like me, who are subsidising the shortfall. It is high hash miner coming in at low difficulty then leaving that have been getting all the over produced coins.
I have added my latest chart showing how my 2 week prediction is now coming true for August, as the over block production is now started going into deficit, see yellow line.
[/quote]I’ve read your concept. First of all, look at PPCoin and Primecoin. Their difficulty adjustment is smooth, though with a high level of inertia. When Primecoin received an huge boost in computing power a few days after the launch, it couldn’t adapt to it quickly. There were too many orphans and huge block overproduction. Look at the charts.
http://cryptometer.org/primecoin_90_day_charts.html
That’s why very long retarget window is unproductive. Furthermore, you’re offering to give the same weights to the past 100, 1000 and 10000 blocks while averaging. It’s going to make the result even worse. The last blocks generated must have preference, so here come either different weights or exponential curve. Our concern is to make difficulty adjustments smooth while to minimise possible negative effects. Need to adjust fast, but not too fast. 32 block retarget delivers smoothing required while 21 hour retarget window provides very good prediction still.
Our last difficulty change was from 170 to 241 and it’s going to be back to 170 again. My retarget algorithm would increase it to ~200 and later back to ~180 depending on exchange rates. No more large network hash rate swings. Loyal miners receive rewards expected, coin hoppers get little benefits. That’s the point.
-
The original concept was that you could easily adjust the weighting dependant on the problem you are trying to solve. In Feathercoins case, the 44% restriction has helped damp the short term variation, but is deficient over 2 weeks. If you want to emphasis short term changes, Av = ( 2 * 100 + 1000 + 10000 ) /4.
I would rather just stick with looking into Feathercoin, as the none scrypt nature makes the other coins situation to Hash attacks different to Feathercoins, we are slightly more secure. Have they really implemented my idea?
P.S. I’ve updated the charts to show the Day, Week and Monthly trends, as they are developing up to August 11th 2013. The red line on weekly is Sunday. Red on Monthly is the start of the month.
[attachment deleted by admin]
