Technical Solution Proposals
-
I have now done a number of Days analysis of the effect of the current Feathercoin Difficulty changing algoryth.
1. The miner levels are very variable, and are only loosely connected to the Difficulty level. I believe the Difficulty of other coins is an outside agent we can’t control. Likewise, coin trading sites, could be manipulated with dubious equations of coin “worth” auto changing miners to Feathercoin.
2. The implementation of 40% minimum difficulty has worked to stabilise coin production, from the wild swings in June. However, the block production has not stabilised at the correct level and is short. This is encouraging over mining.
To address these issues, I suggest we further update the Difficulty change algorithm. Such that it can only change down by 25 %, but can change up by 40%.
All this will mean is that some (currently empty) transactions will not be produced. At the current time, dedicated Featercoin miners are massive takeing the hit of high Difficulty, and loose out when it goes down, when high hash miners pile in.
In the long term the restriction will be meaningless, untill the first ASICs come in and the condition returns that a single or small pool can significantly affect the difficulty and negates the distributed security.
We can continue to monitor block production and further shrink the difficulty change, if required. That is why I have chose 28% over say 32%.
I believe the analysis also indicates that the block difficulty time may also benefit from a slight tweek (downwards). Needs more analysis.
During my recent survey of which countries were connecting to my computer, I note that a small but significant proportion of IP peers node links, were using old versions of the client.
Are they able to mine with old versions? perhaps we should, as a one of measure, ban all version before 6.4.2? I know someone can change the code, but that just makes it harder to do an attack.When miners are confirming a block are they checking that the difficulty change of previous blocks is correct? If not we can enforce this and prevent code based illegal difficulty change on block win.
If we extend the number of confirm blocks and insist on Feathercoin 6.4.3 with added difficulty checking, we would instill a lot of confidence, and prevent early low miner hash attack vectors.
We could also increase the confirm block if the difficulty goes down, again preventing attack when the hash is low.
[attachment deleted by admin]
-
I have noted that some Feathercoin blocks currently have no transactions, especially during “attacks” or low difficulty / Feathercoin “value” changes.
I believe insisting on at least 1 transaction be present to make a successful block, would be very advantageous
Insisting on or taking into account the number of transactions, would have the added advantage of automatically increasing the “effective difficulty” during lean transaction times. It would also make an attacker job harder because they now have to include transaction or some how auto generate them.
A more advanced system could run on an algorithm, “such that” a increasing number of transactions would be required as the difficulty drops.
It would have another advantage as the stored “difficulty” will automatically be used when there are a large amount of transactions and we need the Feathercoin network to process them as quickly as possible, and enforce a Maximum number of transactions per block.
I would tie in with an update that enforced a stricter block timescale band limit.
It would also be a power saving system as the miners could be tweaked to only start mining when there are a minimum number of transactions available. This could be one answer one of the criticisms of Bitcoin it wastes power.
-
[quote name=“wrapper0feather” post=“23956” timestamp=“1375353822”]
I have noted that some Feathercoin blocks currently have no transactions, especially during “attacks” or low difficulty / Feathercoin “value” changes.I believe insisting on at least 1 transaction be present to make a successful block, would be very advantageous
Insisting on or taking into account the number of transactions, would have the added advantage of automatically increasing the “effective difficulty” during lean transaction times. It would also make an attacker job harder because they now have to include transaction or some how auto generate them.
A more advanced system could run on an algorithm, “such that” a increasing number of transactions would be required as the difficulty drops.
It would have another advantage as the stored “difficulty” will automatically be used when there are a large amount of transactions and we need the Feathercoin network to process them as quickly as possible, and enforce a Maximum number of transactions per block.
I would tie in with an update that enforced a stricter block timescale band limit.
It would also be a power saving system as the miners could be tweaked to only start mining when there are a minimum number of transactions available. This could be one answer one of the criticisms of Bitcoin it wastes power.
[/quote]Holding blocks until transactions occur is a cool idea but will just cause problems. You will have fewer coins being generated at the same hash rate. This also opens the door to some new unknown attack vectors on the coin. KISS rule is always the best way to go.
-
[quote name=“RIPPEDDRAGON” post=“23990” timestamp=“1375369793”]
[quote author=wrapper0feather link=topic=1478.msg23956#msg23956 date=1375353822]
I have noted that some Feathercoin blocks currently have no transactions, especially during “attacks” or low difficulty / Feathercoin “value” changes.I believe insisting on at least 1 transaction be present to make a successful block, would be very advantageous
Insisting on or taking into account the number of transactions, would have the added advantage of automatically increasing the “effective difficulty” during lean transaction times. It would also make an attacker job harder because they now have to include transaction or some how auto generate them.
A more advanced system could run on an algorithm, “such that” a increasing number of transactions would be required as the difficulty drops.
It would have another advantage as the stored “difficulty” will automatically be used when there are a large amount of transactions and we need the Feathercoin network to process them as quickly as possible, and enforce a Maximum number of transactions per block.
I would tie in with an update that enforced a stricter block timescale band limit.
It would also be a power saving system as the miners could be tweaked to only start mining when there are a minimum number of transactions available. This could be one answer one of the criticisms of Bitcoin it wastes power.
[/quote]Holding blocks until transactions occur is a cool idea but will just cause problems. You will have fewer coins being generated at the same hash rate. This also opens the door to some new unknown attack vectors on the coin. KISS rule is always the best way to go.
[/quote]One of the golden rules of software development is “Don’t fix what isn’t broken”. Every block includes at least one transaction which credits coins mined. We cannot enforce inclusion of user transactions simply because there are often none pending processing on the network.
-
Ghostlander, I very much value your opinion. I though we were discussing solutions to problems “Technical Solution Proposals is the name thread?.”
I have done a lot of work to suggest a further minor change to validation of a block, al la 40% minimum difficulty change will be successful and is completely in the Satoshi spirit of auto alignment.
I agree with your rule “Don’t fix what isn’t broken” we called it “Design out” when I did maintenance management consultancy. All design outs do have have bugs, that’s why I am proposing only minor adjustments to the code.
-
[quote name=“wrapper0feather” post=“23956” timestamp=“1375353822”]
I have noted that some Feathercoin blocks currently have no transactions, especially during “attacks” or low difficulty / Feathercoin “value” changes.I believe insisting on at least 1 transaction be present to make a successful block, would be very advantageous
[/quote]This is a non solution because I could just generate a transaction with the same output as the input, or one using 2 address I control.
-
[quote name=“KoolKrafter” post=“16939” timestamp=“1371901060”]
We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P
[/quote]Bundling crapware with the client won’t get more people to mine I’m afraid… especially since mining generally doesn’t happen on the client anyway, since the difficulty is too high for solo mining.
-
[quote name=“ego12” post=“18241” timestamp=“1372384398”]
Force everyone to go thru the ftc wallet to mine. Improve it and put checkpoints/chokepoints on it.
[/quote]Doesn’t work that way. It’s not closed source software running a proprietary algorithm, it’s open source software running an open standard. You can’t force anyone to do anything, you can only suggest a protocol that disallows bad behavior and ask people to follow the protocol, and ignore those who don’t.
-
[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.
