Securing the Block Chain
-
[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.
