Securing the Block Chain
-
[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 -
[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.
-
[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.
-
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
-
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.
-
[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?
-
[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.
-
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/sTo 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 votesSo 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 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/sTo 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 votesSo 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%
-
[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.]?
-
[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.
-
[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/sTo 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 votesSo 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).
-
putting 1000 client is not difficult, i can do like 30 on my i5 6G ram with VM each having a different IP.
for the think you know about a node it’s pretty much nothing:
IP: can be as i want mostly. so you know the ip I’m talking to you with but i can have many others.as far as i can get them routed o me it can be any address, i can even assign many to my computer and choose the one to use to talk to any other node. they change also and anode is only connect to few nodes so getting a list of all unique is very expensive in consolidation processing.
Hashrate: nope pool have an idea as you submit share, solo you don’t know you can only extrapolate from time between block found correlated to difficulty
Blocks Found: from your address yes, but you can have other address
Public Key Age: nope the chain only know the first use of it
coin: yes with address
coin age: yes with addressthe big problem is that what the client gives you if you can’t verify it against the chain can be what the sender want it to be if he takes the time to manipulate the code to send that.
in fact the actual POW is a voting system base on hash rate. POS base on coins earn and usually for how long you have them.
for 2 example on how it can be implement please read(they write better then me ;))
[url=https://en.bitcoin.it/wiki/Proof_of_Stake]https://en.bitcoin.it/wiki/Proof_of_Stake[/url]so POS complement to protect POW in both case. PPC, orbit and other has POS also, but most bitcoin forum and other crypto forum discussion about POS have similar conclusion: it is probably not yet safe to keep a coin running on it to choose the chain as distribution of coins is not sufficient to prevent attacks. In most form of POS described: that is probably true, can a POS design be able to make it? I don’t know.
adding a second voting system can be used to checkpoint the first one that is POW. but in fact it makes this second one having the ability to determine a POW winner even if it’s not the biggest work(you still need to find a block, but can invalidate 20 blocks chain with a single block if they have not been checkpointed yet). so this gives a lot of control attacks on this can negate the POW. possible giving an attack that is easier then a 51% POW attack.
note for POS. to participate you need to have your coin in your wallet and run a full node to participate. running a full node all the time is not done by most. exchange are likely to have a lot of coins that can make POS so able to influence POS(possibly manipulate).
-
[quote name=“groll” post=“30993” timestamp=“1381545095”]
note for POS. to participate you need to have your coin in your wallet and run a full node to participate. running a full node all the time is not done by most. exchange are likely to have a lot of coins that can make POS so able to influence POS(possibly manipulate).
[/quote]You nailed it groll. + 1000000000
It’s for this reason that I think it’s powerful. If you want to move your trust, you can. If enough people move their coins away, that entity loses their control on the network. It’s [i]voting through ownership via proxy[/i], and that’s potent because it’s distributed and verifiable by other clients.
-
[quote name=“Kevlar” post=“30965” timestamp=“1381514263”]
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.
[/quote]Got the point, and you are right
-
The reason it’s so difficult to get decentralization in power is because the bitcoin concept only considers physical decentralization. It does not allow for local parameters without hard forks which have to go through exchanges.
Securing localchains would be a lot easier than trying to fix the big thing itself.
Look up the paperless office to see how complicatedness simply shifts around instead of being managed.
-
[quote] 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 e.t.c.]? [/quote]
If you compile the Debug version of the Feathecoin Wallet client from GitHub, there is a debug console. help, lists all the available functions in the client. You can run each one yourself - e.g. getpeerinfo, getdifficulty, gethashespersec etc…
The block chain explorer contains the raw data of blocks produced and difficulty.
At the moment, the human element and the effects of recent software changes need monitoring (before any further adjustments are made). Feathercoin is in a novel situation, which means we cannot rely on past experience. Also, solutions I would have argued as nonsense a couple of months ago might now be relevant.
My advice is monitor, identify problems, develop solution to problem, implement solution, monitor effect of solution, etc
Perhaps the question I would like to see answered, what security updates are available in 0.8.5 (of Litecoin / Bitcoin) and which are we going to implement / take advantage of, if any?
The main thing we could do to increase security is to encourage a significant number of miners, compared to the power of a potential attacker or pool.
-
0% PoS is a very good idea in general. There are some issues though. While 0% PoS doesn’t produce any coins, these PoS blocks break PoW coin distribution as scheduled by design. For instance, Feathercoin block reward is halved every 840K blocks until ~336 million coin supply is reached. If zero reward PoS blocks are included in the calculation, the coin supply is lower than expected. If not included, the coin distribution takes more time than expected.
