Technical Solution Proposals
-
[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]Make sure you add that feedback (blue icon on right"Your ideas for Feathercoin"). :)
-
[quote name=“justabitoftime” post=“16949” timestamp=“1371904257”]
[quote author=KoolKrafter link=topic=1478.msg16939#msg16939 date=1371901060]
We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P
[/quote]Make sure you add that feedback (blue icon on right"Your ideas for Feathercoin"). :)
[/quote]I think I must be blind because I can’t see it :P
Maybe a proxy that can filter out all of the bad traffic. I suppose then if it was DDOSed it would screw up the entire network. I don’t know if this would work but maybe implement that into the client so everything has to be verified by someone else?
-
Which browser are you using? It shows in both IE and Firefox on this side.
[attachment deleted by admin]
-
Oh I got it now. Thanks =)
I was using Chrome. Just didn’t want to show up.
-
I would suggest the client gets rebuild and works like this:
- If client gets started some checks against hardware on host are done
- check for known gpu or fallback to cpu
- build-in miner starts at 1% of known resource
This can’t be disabled because it’s a need for help with decentralization
-
if an attack against ftc is happening, arent there indicators for that?
Something that runs out of normality - from the start the attack is beeing performed?If it works that way, that an attack can be detected because specific parameters change immediately because of the attack, we need to have a program watching and controlling this parameters 24/7
-
first we had one category of attack related to 51%, other can occur and possibly to a lesser extend have occur that we just not have been seen as it’s small disruption not major (I suspect some pool have been time warp during 51%, but this can’t be confirm (I just have 2-3 weird coincidence of weird times)so look t it later if needed). but I think we should look at 51% attack as this is the most concerning one at the moment.
first 51% occur on low hash rate this is the pre condition (how low is a big question at first I said the time indicate block at 6 min at 188 diff for 2.5Gh/s from the attacker, but he proves after he manipulate the time so need to take the difference between the previous block and next block found by non attacker divided by the number of block from the attacker in it and alternate chain to find out the real time between blocs so his real hash rate, even so this would be his minimum)
for the attack nothing can warn about it, absolutely nothing can detect it before it is done at the moment. as releasing 6 blocs to invalidate 5 from legitimate chain can occur instantly. the attacker hold and release all at the same time or gradually if he want.
we have misbehavior that occur before or during, but are not needed for the attack.
- big spending (will be double spend and erase in the new chain) this is a pre-condition
- invalidating block with recent time stamp with older blocks
[b]so invalidating more then 2 blocks in one reorganisation or more then 3 time one in 10 block are what can be the absolute way to detect 51% attacks, can occur once or twice a year for network issues.[/b]
Bitcoin on blockchain.info has a very nice display of split. you will see that for bicoin no longer orphan chain then 1 block have occur since march 25. you can also see the very long split from the incompatibility between 0.7 and 0.8 version on march 12. (orphaned is on the right side, red X is end of the orphan chain --> means goto next block)
http://blockchain.info/orphaned-blocksyou can do this manually in the explorer by clicking next or previous(depending where you start and where you want to look) on a block and any next with 2 entries is a split, the top block is the chain the second the orphan. if you click the orphan and he has no next the orphan chain is 1 long and has ended(usually normal). if it has a next then same process. if you get 4 or more in the orphan and are after block 34000 in the chain of feathercoin send me a PM I will analyse it with you as you probably found something. As far as I know none occur after 34000. I check mostly every day many blocks (between 100 and 500) but my time is limited and 500-600 every day is a bit too much block to check all manually for the time I have. (I also check other things but will not disclose it so it can still be used to help my manual process until something is in place to detect or better prevent it from happening)
-
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.
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.
-
Enforce a “Minimum Transaction Time”,
It could be temporary, just if an insertion attack or fork is suspected.
We could then roll back to the last “auto checkpoint” and re-mine those blocks later after the attack. It could be an “variable” update that passed around the system like the difficulty, in the block chain.
Also, if there are negative confirms, where confirms are taken away if certain parameter are outside their normal standard deviation, for a variable or set number of blocks. i.e. average block size for last 5 block = X. If next block is outside of the standard deviation of X, all other nodes but attacker give it - 1 confirm. Or If there are too many blocks per miniute…
All of the inserted blocks have no real transactions. I would prefer we look to technology / partners / miners agreement roll those attack back.
I would also suggest automatic fork detection mode. If a fork is detected, preferably automatically due to monitored discrepancy rate, or difficulty change. The miners go into re-mine mode, each block would be retested for consistency " with enhanced error monitoring / averages over time), into the a new blockchain, and distributed. Correct block would be renumbered to the new Blockchain, for debug incorrect blocks to a trash.
I propose an open report on all attacks, from feathercoin security section
I believe it will not be a problem soon for Feathercoin , once the number of miners increases and if we are in the software centres and can auto upgrade if there is a security risk.
But:
Fighting these attack is essential, it will cause pollution of the all the crypto currency environment, where there is already lots of scam coin, obviously just made to cause a stink. I particularly see phenixcoin and worldcoin as very vunerable. -
Why should the number of miners increase?
People loosig faith … -
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.
