Feathercoin daemon and wallet production version 0.17.0.2

Securing the Block Chain


  • | Tip tuneman1980

    I noticed Kevlar’s post and am curious to see what ideas the community has for tweaks or innovations that will help to make the Feathercoin block chain more secure. I don’t currently have any ideas, but I have a feeling that Kevlar does.


  • Moderators | Tip wrapper

    In my opinion, we supply the wallet, at this stage of development, it is incumbent on the user to keep the wallet safe. As you would with your normal wallet"

    If there isn’t list, “Feathercoin Health and Safety”, then perhaps there need to be. I’m sure you can increase your anon, by simple means at this stage.

    1. Use a separate address for all transactions.
    2. Transfer funds through alternate coins.

    Also, it would be diverting to include extra software development, unless a particular failure has been identified.

    Major changes in the philosophy of a coin have problematic, it is usually decided these should major changes should be done as least as possible, i.e. the need for stability and truth to the original users expectations, past reliability effecting future risk.

    I have made a suggestion previously that major changes, such as security measures rates and anonomising should be considered for FeathercoinFree or Feathercoin2 (or whatever name we give the next “Feathercoin Franchise” coin, i.e. if the market expands greatly and we need to split the blocks.)


  • Spammer Banned | Tip Kevlar

    [quote name=“wrapper0feather” post=“30791” timestamp=“1381341782”]
    In my opinion, we supply the wallet, at this stage of development, it is incumbent on the user to keep the wallet safe. As you would with your normal wallet"

    If there isn’t list, “Feathercoin Health and Safety”, then perhaps there need to be. I’m sure you can increase your anon, by simple means at this stage.

    1. Use a separate address for all transactions.
    2. Transfer funds through alternate coins.

    Also, it would be diverting to include extra software development, unless a particular failure has been identified.

    Major changes in the philosophy of a coin have problematic, it is usually decided these should major changes should be done as least as possible, i.e. the need for stability and truth to the original users expectations, past reliability effecting future risk.

    I have made a suggestion previously that major changes, such as security measures rates and anonomising should be considered for FeathercoinFree or Feathercoin2 (or whatever name we give the next “Feathercoin Franchise” coin, i.e. if the market expands greatly and we need to split the blocks.)
    [/quote]

    I think the topic tuneman1980 is suggesting is about the blockchain itself, not user’s private keys, although that’s certainly another topic that warrants a lot of discussion! Perhaps we should start a separate thread called “End-user security”?

    I’m still working on the securing the block chain post. I hope to have it done tonight.


  • Regular Member | Tip zerodrama

    Well maybe we should ask woodland creatures how they stay safe. I’m not joking. Convert survival from wildlife to metaphor to code. Have some fun in the process.


  • Regular Member | Tip erk

    Peer consensus timstamps need replacing with something more robust, NTP or another Internet time source should be used, that way you can have accurate timestamps and introduce a tighter controls on what constitutes a valid block from a miner.

    Also the block chain will eventually need pruning, ATM the BTC client takes two days to sync a full block chain, that’s a serious problem for someone running a pool or exchange to be down for days. A strategy needs to be put in place well before the FTC block chain grows that large.


  • Spammer Banned | Tip Kevlar

    [quote name=“erk” post=“30830” timestamp=“1381394609”]
    Peer consensus timstamps need replacing with something [u]more robust[/u], NTP or another Internet time source should be used
    [/quote]

    You spelled “more centralized” wrong.

    There’s nothing wrong with the protocol as it’s designed. Clients reject transactions that are outside a given time range from their current system time. This provides a decentralized timestamp consensus which relies on no outside authority, only group consensus. If 51% of the miners rely on some reasonably accurate time source for their system time, designating a centralized oracle for timestamps is unnecessary.

    [quote]Also the block chain will eventually need pruning[/quote]

    It’s being worked on:
    https://bitcointalk.org/index.php?topic=88208.0
    https://bitcointalk.org/index.php?topic=204283.0


  • Regular Member | Tip erk

    [quote name=“Kevlar” post=“30855” timestamp=“1381426655”]
    [quote author=erk link=topic=3952.msg30830#msg30830 date=1381394609]
    Peer consensus timstamps need replacing with something [u]more robust[/u], NTP or another Internet time source should be used
    [/quote]

    You spelled “more centralized” wrong.

    There’s nothing wrong with the protocol as it’s designed. Clients reject transactions that are outside a given time range from their current system time. This provides a decentralized timestamp consensus which relies on no outside authority, only group consensus. If 51% of the miners rely on some reasonably accurate time source for their system time, designating a centralized oracle for timestamps is unnecessary.

    [/quote]Time is a referenced standard, [b]not something a PC mining can determine by itself.[/b] There are many time serving atomic clocks on the Internet, it’s not centralized.


  • Spammer Banned | Tip Kevlar

    [quote name=“erk” post=“30873” timestamp=“1381436827”]
    [quote author=Kevlar link=topic=3952.msg30855#msg30855 date=1381426655]
    [quote author=erk link=topic=3952.msg30830#msg30830 date=1381394609]
    Peer consensus timstamps need replacing with something [u]more robust[/u], NTP or another Internet time source should be used
    [/quote]

    You spelled “more centralized” wrong.

    There’s nothing wrong with the protocol as it’s designed. Clients reject transactions that are outside a given time range from their current system time. This provides a decentralized timestamp consensus which relies on no outside authority, only group consensus. If 51% of the miners rely on some reasonably accurate time source for their system time, designating a centralized oracle for timestamps is unnecessary.

    [/quote]Time is a referenced standard, [b]not something a PC mining can determine by itself.[/b] There are many time serving atomic clocks on the Internet, it’s not centralized.
    [/quote]

    Mining doesn’t NEED to determine it by itself, it just NEEDS to form a consensus among 51% of miners independent of any outside reference. The consensus can be completely arbitrary, so long as 51% agree to it. The minute anyone deviates outside the consensus, the client will reject the block.

    What your worrying about is that 51% of the network will deviate from the reference standard, which means we’re back to solving the 51% distribution problem, not the time reference problem.


  • Regular Member | Tip erk

    [quote name=“Kevlar” post=“30874” timestamp=“1381438233”]
    [quote author=erk link=topic=3952.msg30873#msg30873 date=1381436827]
    [quote author=Kevlar link=topic=3952.msg30855#msg30855 date=1381426655]
    [quote author=erk link=topic=3952.msg30830#msg30830 date=1381394609]
    Peer consensus timstamps need replacing with something [u]more robust[/u], NTP or another Internet time source should be used
    [/quote]

    You spelled “more centralized” wrong.

    There’s nothing wrong with the protocol as it’s designed. Clients reject transactions that are outside a given time range from their current system time. This provides a decentralized timestamp consensus which relies on no outside authority, only group consensus. If 51% of the miners rely on some reasonably accurate time source for their system time, designating a centralized oracle for timestamps is unnecessary.

    [/quote]Time is a referenced standard, [b]not something a PC mining can determine by itself.[/b] There are many time serving atomic clocks on the Internet, it’s not centralized.
    [/quote]

    Mining doesn’t NEED to determine it by itself, it just NEEDS to form a consensus among 51% of miners independent of any outside reference. The consensus can be completely arbitrary, so long as 51% agree to it. The minute anyone deviates outside the consensus, the client will reject the block.

    What your worrying about is that 51% of the network will deviate from the reference standard, which means we’re back to solving the 51% distribution problem, not the time reference problem.
    [/quote]Ok I will spell it out, the current timestamps are vulnerable to a 51% attack, you want to secure the block chain you need to fix that.


  • Spammer Banned | Tip Kevlar

    [quote name=“erk” post=“30881” timestamp=“1381445138”]
    [quote author=Kevlar link=topic=3952.msg30874#msg30874 date=1381438233]
    [quote author=erk link=topic=3952.msg30873#msg30873 date=1381436827]
    [quote author=Kevlar link=topic=3952.msg30855#msg30855 date=1381426655]
    [quote author=erk link=topic=3952.msg30830#msg30830 date=1381394609]
    Peer consensus timstamps need replacing with something [u]more robust[/u], NTP or another Internet time source should be used
    [/quote]

    You spelled “more centralized” wrong.

    There’s nothing wrong with the protocol as it’s designed. Clients reject transactions that are outside a given time range from their current system time. This provides a decentralized timestamp consensus which relies on no outside authority, only group consensus. If 51% of the miners rely on some reasonably accurate time source for their system time, designating a centralized oracle for timestamps is unnecessary.

    [/quote]Time is a referenced standard, [b]not something a PC mining can determine by itself.[/b] There are many time serving atomic clocks on the Internet, it’s not centralized.
    [/quote]

    Mining doesn’t NEED to determine it by itself, it just NEEDS to form a consensus among 51% of miners independent of any outside reference. The consensus can be completely arbitrary, so long as 51% agree to it. The minute anyone deviates outside the consensus, the client will reject the block.

    What your worrying about is that 51% of the network will deviate from the reference standard, which means we’re back to solving the 51% distribution problem, not the time reference problem.
    [/quote]Ok I will spell it out, the current timestamps are vulnerable to a 51% attack, you want to secure the block chain you need to fix that.
    [/quote]

    Correct! That means enforcing a distribution of hashing power within the protocol. As I said earlier I’m still working on that post, but any suggestions for changes to the protocol in order to enforce proper distribution prior to my suggestions would be most welcome.


  • Regular Member | Tip groll

    I will start with the time problem.

    Client need to accept block when they arrive, if you open your client the block 2 days old need to b accepted with the timestamp in it so current time is not usefull. the ay it is done is that the blocks are validate to not be too much in future and not too much in the past. the future is now 30 minutes from now. ACp remove this but it would not be impossible for someone without acp to begin to mine at the last block of a retarget with a time way in the future and then release the chain only when in time range, and continue his chain with a lower retarget.

    the 9% been small help us here a bit, but lets make an example with the old 1.41 so we get a very easy to see example. let say the network is at 503 block of a low diff at 160 and will retarget at 225 for a 12h run. the attacker begin to mine at the 503 and put in his not yet release chain the 504 block 18 hour later in fact getting 1.41 down to 113 as it is a 504 with 30h. so he can mine a chain with significantly lower hash rate then the network and get a longer chain(30%). he can release his chain after the 18h are pass with all his new chain at a small time after the first one to get back the 160 retarget and repeat.

    let say he release after 20h so his block are 2 hour old. since it’s block are in the past the client can only validate against the surrunding chain. else any client that is at some point isolate from the network would not be able to reorganize and get back to the “concensus” chain.

    so what is used is that a block can’t go back in time from the mean of the previous one and if get now can’t get in future too much. (machine time can be off in time a bit even when using NTP as it use drift and not instantaneous corrections). the fact is that the miner put the time in the block, normal client would put correct time a rogue one can put what he want and unless it is certified(signed) no one can verify what is put is real at the time it is pu. other can only validate the it’s in range so possibly valide.

    on a side note window and most network credential exchanged like kerberos, saml, etc usually use a ± 15 minutes window for token as time can vary and delay can happen. so validating in a range is standard way in distributed environment.

    so what we have it’s an orphaning of a long part of the chain. and this is what ACP prevent as you can’t do it more then 3 blocks old. time can still be manipulate but would be difficult to sustain even with more then 50%. a limit has been added for the past time to be less then one hour before the last block so the legitimate network should never be able to make a current time block been checkpointed. so the legitimate network should never be able to find 3 locks in row before they get orphan by the attacker. this would approximatly require more then 75% of the hashrate to be possible with greater the 90% chance of success over a 20h period. and he attacker would not benefit form been on a lower diff chain for more the 3 blocks.

    setting a min max time between block is not an option! few seconds between 2 blocks is possible and like we had in may 1 hour between 2 blocks is also possible (we don’t want that but still something that unfortunately can happen).

    one technic exists that is the digital timestamping where an authority sign a timestamp with a hash to prove it was done at that time. in fact that is what the block chain do in a decentralise way so using a centralize timestamper don’t make sense in my mind. this only prevent you from stamping the hash at another point in time but it don’t prevent you from waiting a long time before timestamping it. if used to construct next block it will prevent precalculation to orphan chain with wrong timestamp. not orhaning it.

    time is one manipulation that most miner see, long chain orphaning has way more bad side one of then is double spend, another is reject any transaction to be confirm. so long orphan should be prevented. so the question that most would say is why allow reorganize? the reason is that you can be on the wrong fork (as some pool have been and possibly some client still are in the pre client 0.6.4.4 protocol chain and are in around block 88300) so when they update they need to reoganize and get to the new chain. this is one easy to understand example, but other reason can make a client follow a “wrong” chain. The big question is how to make sure the “concensus” chain is not replace. the actual solution is ACP and is what should be enhanced, replace ,etc. by something more decentralize.

    the bitcoin protocol concider that you can’t get enough power to overtake the network, this was possibly a good assomption for bitcoin as it was and as it is still the principal coin. for alt this is not true as hash power of attacker is enough to overtake the coins when time correctly.

    so a form of checkpointing need to be done, but by the network not by a central authority. similarly to the current mining network isolation and other glitches makes the decentralization of checkpointing a difficult task. you can’t just let the network checkpoint if you get a network split you can get two checkpoint at same blocks height for 2 different block and then your screwed.

    POS is a form of checkpointing and have been discuss and implement in many coin. each having some change in the way POS is used. some consume the coin age, some just use it. but in all if you get a significant amount of coins sitting for long time you can make a POS 51% attack (it’s 51% of the vote not 51% of the coins). since not all coins are used in POS a 51% can take a lot less then 51% of the total coins especially when it consume coin age as timing in use of coin age can make a POS 51% possible with less then 1% of the coin and it is known that 3-4 address has more then 300K coin from the 30000-40000 blocks and still have not move them(6oADBx5Xxhc273rnppgNDP4dHzgrsbtxjE from 33789 is one of them and the coins are 3 transactions away from coins used in the attacks so possibly still on the hand of the attacker).

    I’ll continue in next few days as my time for today is over. I need to go to sleep. but should be enough to start some discussion


  • Moderators | Tip Wellenreiter

    Good resume, Groll. I’m relatively new to cryptocurrencies, but I understood your desciption.

    One possibility to secure the chain could be, that miners/pools can ‘gain reputation’ based on some measurements on the blockchain, or based on a reputation system comparable to the one here in the Forum.

    It could work like: ‘I know this pool and trust it, so I give a reputation point’, or a miner/pool gets a point for every block found, counting only single blocks seen by the network, and one or more points are deducted for every chain of blocks injected.

    Based on the reputation a miner or pool has, a limitation of the length of chain, that can be injected could be calculated.

    It’s not based on pure calculation, but some human intervention could be needed to give the ‘rep points’

    IT also may be that I’m talking nuts, but this came into my mind.


  • Spammer Banned | Tip Kevlar

    [quote name=“groll” post=“30902” timestamp=“1381464583”]

    the bitcoin protocol concider that you can’t get enough power to overtake the network, this was possibly a good assomption for bitcoin as it was and as it is still the principal coin. for alt this is not true as hash power of attacker is enough to overtake the coins when time correctly.

    so a form of checkpointing need to be done, but by the network not by a central authority. similarly to the current mining network isolation and other glitches makes the decentralization of checkpointing a difficult task. you can’t just let the network checkpoint if you get a network split you can get two checkpoint at same blocks height for 2 different block and then your screwed.

    POS is a form of checkpointing and have been discuss and implement in many coin. each having some change in the way POS is used. some consume the coin age, some just use it. but in all if you get a significant amount of coins sitting for long time you can make a POS 51% attack (it’s 51% of the vote not 51% of the coins). since not all coins are used in POS a 51% can take a lot less then 51% of the total coins especially when it consume coin age as timing in use of coin age can make a POS 51% possible with less then 1% of the coin and it is known that 3-4 address has more then 300K coin from the 30000-40000 blocks and still have not move them(6oADBx5Xxhc273rnppgNDP4dHzgrsbtxjE from 33789 is one of them and the coins are 3 transactions away from coins used in the attacks so possibly still on the hand of the attacker).
    [/quote]

    Perfectly articulated groll! VERY well done.

    PoS is a good solution in my mind because when you combine it with PoW it makes attacking the blockchain VERY expensive from both a time AND resources perspective. It can be done in a way that doesn’t change the block reward too, because that may be undesirable due to the fact that the currency would become inflationary instead of deflationary… albeit still at a controlled and easily predicted rate. What are your thoughts regarding 0% PoS?


  • Spammer Banned | Tip Kevlar

    [quote name=“Wellenreiter” post=“30929” timestamp=“1381491935”]
    One possibility to secure the chain could be, that miners/pools can ‘gain reputation’ based on some measurements on the blockchain, or based on a reputation system comparable to the one here in the Forum.

    It could work like: ‘I know this pool and trust it, so I give a reputation point’, or a miner/pool gets a point for every block found, counting only single blocks seen by the network, and one or more points are deducted for every chain of blocks injected.

    Based on the reputation a miner or pool has, a limitation of the length of chain, that can be injected could be calculated.

    It’s not based on pure calculation, but some human intervention could be needed to give the ‘rep points’
    [/quote]

    I see no way to enforce this at the protocol level without destroying anonymity and centralizing power. Anything that requires tying identity to the blockchain, Human intervention, or centralizing power should not be considered. If you have a technical solution for how to address these, please follow up with it here.


  • | Tip mnstrcck

    I was thinking about this - and actually did some reading to understand things better. I’m still left with a lot of questions on some details, so pardon the following if it’s totally undoable:

    Would it be possible to automate the checkpointing system by a “voting” system that uses weighted averaging?

    Let’s assume a tiny network with three nodes - the global hashrate of this network is [b]600 kh/s[/b] at block [i]x[/i]

    Node 1 - 300 kh/s
    Node 2 - 200 kh/s
    Node 3 - 100 kh/s

    To vote on the checkpoint, the system looks at each node’s hashrate, and calculates a vote multiplier on each node so that all nodes’ voting power in hashrate is equal:

    [b]Network Average Node Hashrate[/b] is [b]200 kh/s[/b] - this is our 1 vote average, anything above or below get’s adjusted, so:

    Node 1 - 0.66666667 of a vote
    Node 2 - 1 vote
    Node 2 - 2 votes

    So now, it’s not longer who has the biggest hashrate that decides. Only issue I see is if someone is using a botnet [but I am still trying to figure out exactly how those work, I imagine it’s like a pool].


  • Regular Member | Tip groll

    [quote name=“mnstrcck” post=“30971” timestamp=“1381519883”]
    I was thinking about this - and actually did some reading to understand things better. I’m still left with a lot of questions on some details, so pardon the following if it’s totally undoable:

    Would it be possible to automate the checkpointing system by a “voting” system that uses weighted averaging?

    Let’s assume a tiny network with three nodes - the global hashrate of this network is [b]600 kh/s[/b] at block [i]x[/i]

    Node 1 - 300 kh/s
    Node 2 - 200 kh/s
    Node 3 - 100 kh/s

    To vote on the checkpoint, the system looks at each node’s hashrate, and calculates a vote multiplier on each node so that all nodes’ voting power in hashrate is equal:

    [b]Network Average Node Hashrate[/b] is [b]200 kh/s[/b] - this is our 1 vote average, anything above or below get’s adjusted, so:

    Node 1 - 0.66666667 of a vote
    Node 2 - 1 vote
    Node 2 - 2 votes

    So now, it’s not longer who has the biggest hashrate that decides. Only issue I see is if someone is using a botnet [but I am still trying to figure out exactly how those work, I imagine it’s like a pool].
    [/quote]

    sorry for the short answer that I just have 1 minutes so without sugar coating 😉

    unfortunatly with the 200k i would just make 1000 client with fraction of .2k each so I get 1000 votes for each of the 1000 miner so 1M vote (no really true as average will be lower, but you get the idea). so now I control the chain without even close to 51%


  • Regular Member | Tip erk

    [quote name=“mnstrcck” post=“30971” timestamp=“1381519883”]
    I was thinking about this - and actually did some reading to understand things better. I’m still left with a lot of questions on some details, so pardon the following if it’s totally undoable:

    Would it be possible to automate the checkpointing system by a “voting” system that uses weighted averaging?

    Let’s assume a tiny network with three nodes - the global hashrate of this network is [b]600 kh/s[/b] at block [i]x[/i]

    Node 1 - 300 kh/s
    Node 2 - 200 kh/s
    Node 3 - 100 kh/s

    To vote on the checkpoint, the system looks at each node’s hashrate, and calculates a vote multiplier on each node so that all nodes’ voting power in hashrate is equal:

    [b]Network Average Node Hashrate[/b] is [b]200 kh/s[/b] - this is our 1 vote average, anything above or below get’s adjusted, so:

    Node 1 - 0.66666667 of a vote
    Node 2 - 1 vote
    Node 2 - 2 votes

    So now, it’s not longer who has the biggest hashrate that decides. Only issue I see is if someone is using a botnet [but I am still trying to figure out exactly how those work, I imagine it’s like a pool].
    [/quote] I was thinking on a similar line, we need a score system that each client builds up over lime, not unlike the Bayesian database that’s built up by a modern spam filter. In the feathercoin.conf file you should be able to list trusted peers that get a higher score, so if a fork is encountered the client will prefer the chain from the peers with the highest score.


  • | Tip mnstrcck

    [quote name=“groll” post=“30972” timestamp=“1381522928”]
    unfortunatly with the 200k i would just make 1000 client with fraction of .2k each so I get 1000 votes for each of the 1000 miner so 1M vote (no really true as average will be lower, but you get the idea). so now I control the chain without even close to 51%
    [/quote]

    Getting 1000 clients all to be on the same page to attack a blockchain seems like it would be quite a bit of work. I’m wondering if there’s other conditions that we can set to avoid something like this. IP address for example. We can apply “vote” ceilings/floors as well so 0.2 won’t be as substantial in value. Something like hashrate = below/above[i]x[/i] (where [i]x[/i] is a minimum or maximum) = maxvote [and we set max vote value as 0.11 or 11 etc]

    Would anyone be so kind as to give me an idea of what parameters the network can know about each node [IP, Hashrate, Blocks Found, Public Key Age etc.]?


  • Spammer Banned | Tip Kevlar

    [quote name=“mnstrcck” post=“30989” timestamp=“1381541478”]

    Getting 1000 clients all to be on the same page to attack a blockchain seems like it would be quite a bit of work.
    [/quote]

    No, it would be trivial. Virtualization + puppet/chef. Done.


  • Spammer Banned | Tip Kevlar

    [quote name=“erk” post=“30986” timestamp=“1381538386”]
    [quote author=mnstrcck link=topic=3952.msg30971#msg30971 date=1381519883]
    I was thinking about this - and actually did some reading to understand things better. I’m still left with a lot of questions on some details, so pardon the following if it’s totally undoable:

    Would it be possible to automate the checkpointing system by a “voting” system that uses weighted averaging?

    Let’s assume a tiny network with three nodes - the global hashrate of this network is [b]600 kh/s[/b] at block [i]x[/i]

    Node 1 - 300 kh/s
    Node 2 - 200 kh/s
    Node 3 - 100 kh/s

    To vote on the checkpoint, the system looks at each node’s hashrate, and calculates a vote multiplier on each node so that all nodes’ voting power in hashrate is equal:

    [b]Network Average Node Hashrate[/b] is [b]200 kh/s[/b] - this is our 1 vote average, anything above or below get’s adjusted, so:

    Node 1 - 0.66666667 of a vote
    Node 2 - 1 vote
    Node 2 - 2 votes

    So now, it’s not longer who has the biggest hashrate that decides. Only issue I see is if someone is using a botnet [but I am still trying to figure out exactly how those work, I imagine it’s like a pool].
    [/quote] I was thinking on a similar line, we need a score system that each client builds up over lime, not unlike the Bayesian database that’s built up by a modern spam filter. In the feathercoin.conf file you should be able to list trusted peers that get a higher score, so if a fork is encountered the client will prefer the chain from the peers with the highest score.
    [/quote]

    That sounds similar to proof of stake, just minus the proof, and the stake. PoS works because it requires an attacker to invest in ownership, which is provable. Time of an ip on the network doesn’t prove anything since ip addresses can be shared (ala NAT).