Using Litecoin To Protect Bitcoin Versus 51% Attacks - By Casascius

[fryarminer]

Well theoretically if you had the processing power to attack bitcoin, couldn't you just attack litecoin, and change the rules around including bitcoin hashes, or whatetever, before attacking bitcoin ? 

No, because SHA256 and scrypt don't use the same asic hardware, so to have 51% power in both would be near illogical, if not impossible.

[darkota]

Well theoretically if you had the processing power to attack bitcoin, couldn't you just attack litecoin, and change the rules around including bitcoin hashes, or whatetever, before attacking bitcoin ? 

No, because SHA256 and scrypt don't use the same asic hardware, so to have 51% power in both would be near illogical, if not impossible.

That makes no sense. To get 51% of the hashrate in Litecoin is relatively Very Cheap to get 51% hashrate in Bitcoin.

Scrypt and SHA256 are very similar, I don't know what world youre living in fryarminer.

[smoothie]

If you read the original thread when Mike penned it I was in support of his original idea presented there.

Not sure what happened and why it was not implemented.

Charlie care to remind us why?

[jonald_fyookball]

the original proposal advocates getting rid of the longest chain rule for
bitcoin in favor of some bizarre check against litecoin.

for that reason, it's mostly likely a very bad idea and not
even worthy of a core dev to comment on.

[ChuckStrawberry]

its only time until a notable coin suffers a 51%. that will probably jump us up in adoption

[doo]

What exactly is the point of bringing a dead and buried discussion back up? OP must rate his life very cheaply to waste his precious time going through thousands of archival pages.

[Bitcoin Magazine]

PPcoin is superior to Bitcoin in every shape and form.  Why not use that?

[m3]

yes if one of bitcoin's pools gets close to 51% its best to move to another coin. But I think vertcoin is a better solution then litecoin because the distribution of the mining pool is more even.

[CoinHoarder]

the original proposal advocates getting rid of the longest chain rule for
bitcoin in favor of some bizarre check against litecoin.

for that reason, it's mostly likely a very bad idea and not
even worthy of a core dev to comment on.

The way I understand, it doesn't effect Bitcoin unless it is under a 51% attack and more than one chain pops up. It would be a back up to the way Bitcoin determines a valid chain, only to be used in extreme circumstances.

PPcoin is superior to Bitcoin in every shape and form.  Why not use that?

PPcoin could be used to do this, and I think alternatives should be looked into if Litecoin wouldn't want to. In fact, they seem downright hostile towards the idea so maybe it should be done on a different chain. It doesn't have to be Litecoin at all. Since Litecoin uses a different algorithm though, it would require building two different types of ASICs to 51% either network. Any coin with a different algorithm, or one secured by PoS like PPcoin would suffice.

yes if one of bitcoin's pools gets close to 51% its best to move to another coin.

If this were implemented, then it pretty much negates 51% attack unless the attacked can also gain a hold of the Litecoin network too.

[jonald_fyookball]

the original proposal advocates getting rid of the longest chain rule for
bitcoin in favor of some bizarre check against litecoin.

for that reason, it's mostly likely a very bad idea and not
even worthy of a core dev to comment on.

The way I understand, it doesn't effect Bitcoin unless it is under a 51% attack and more than one chain pops up. It would be a back up to the way Bitcoin determines a valid chain, only to be used in extreme circumstances.
 

I don't think so.

It says this:

In the event there is an active Bitcoin block chain fork, the requirement is loosened such that the Bitcoin block header hash requirement can be satisfied by any leg of the chain, not just the one Bitcoin considers valid.

.

Do you see why this doesn't make any sense?  You're messing with one of the key parts of the Bitcoin system and actually making it much easier to attack.

[CoinHoarder]

the original proposal advocates getting rid of the longest chain rule for
bitcoin in favor of some bizarre check against litecoin.

for that reason, it's mostly likely a very bad idea and not
even worthy of a core dev to comment on.

The way I understand, it doesn't effect Bitcoin unless it is under a 51% attack and more than one chain pops up. It would be a back up to the way Bitcoin determines a valid chain, only to be used in extreme circumstances.
 

I don't think so.

It says this:

In the event there is an active Bitcoin block chain fork, the requirement is loosened such that the Bitcoin block header hash requirement can be satisfied by any leg of the chain, not just the one Bitcoin considers valid.

.

Do you see why this doesn't make any sense?  You're messing with one of the key parts of the Bitcoin system and actually making it much easier to attack.

No, I don't understand your point. Why specifically would it make it much easier to attack? I think it would do the opposite.

[jonald_fyookball]

currently, if there is a fork, consensus is reached by using the longest chain rule.
a doublespend attack means you are secretly mining a separate chain that has to be
longer than the main chain.  to do that is very expensive requiring lots of hashing power.

this proposal says to get rid of that scheme and use a different one involving litecoin.
and litecoin requires much less hashing power.

[CoinHoarder]

currently, if there is a fork, consensus is reached by using the longest chain rule.
a doublespend attack means you are secretly mining a separate chain that has to be
longer than the main chain.  to do that is very expensive requiring lots of hashing power.

Yes I agree.

this proposal says to get rid of that scheme and use a different one involving litecoin.
and litecoin requires much less hashing power.

This I disagree with though, because someone would need to attack both the Litecoin AND Bitcoin network at the same time. Bitcoin could add in the same checks for Litecoin, so in order to attack Litecoin you'd have to attack Bitcoin too. This would increase security of both coins if implemented properly.

You do realize Litecoin has ASICs now, and the hash power has been exponentially growing for the past 6 months? It is not what I would call easy to 51% the Litecoin network at the moment. If you simply looked at the hash speed (515 Gh), it may seem like that is small compared to Bitcoin. However, you need to take into account that Scrypt is much less efficient than SHA256. You would need to develop/buy Scrypt and SHA256 ASICs to 51% attack the Bitcoin or Litecoin network, making an attack much more expensive. Therefore making it much harder to attack.

Yes, it is different from the way Bitcoin has resolved these issues in the past, but that doesn't automatically make it less secure.

[jonald_fyookball]

This I disagree with though, because someone would need to attack both the Litecoin AND Bitcoin network at the same time. 

Yes, BUT the attack on Bitcoin would be much much cheaper if all you had to do was create a block
and your chain didn't have to be longer than the networks'. 

[CoinHoarder]

This I disagree with though, because someone would need to attack both the Litecoin AND Bitcoin network at the same time.  

Yes, BUT the attack on Bitcoin would be much much cheaper if all you had to do was create a block
and your chain didn't have to be longer than the networks'.  

I see where you are going. This is what Mike proposed in that case:

3. Add a feature to Litecoin clients that allow Litecoin users to decide to prefer or not-prefer branches of a Bitcoin fork while one is in progress.  The default for this should always favor the Bitcoin leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitcoin block chain.  The user/miner/pool-op should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing Bitcoin blocks.

I feel like this may be able to be improved upon if a lot of people thought about it. Do you see a glaring issue in the idea? The way it was stated may not be the best way to implement it, but the idea seems like it could work.

The main chain would be quite long compared to the attacker's chain, so it seems like the client could pick up on which blocks are valid and invalid by comparing the size of the chains.

[jonald_fyookball]

This I disagree with though, because someone would need to attack both the Litecoin AND Bitcoin network at the same time.  

Yes, BUT the attack on Bitcoin would be much much cheaper if all you had to do was create a block
and your chain didn't have to be longer than the networks'.  

I see where you are going. This is what Mike proposed in that case:

3. Add a feature to Litecoin clients that allow Litecoin users to decide to prefer or not-prefer branches of a Bitcoin fork while one is in progress.  The default for this should always favor the Bitcoin leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitcoin block chain.  The user/miner/pool-op should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing Bitcoin blocks.

I feel like this may be able to be improved upon if a lot of people thought about it. Do you see a glaring issue in the idea? The way it was stated may not be the best way to implement it, but the idea seems like it could work.

The main chain would be quite long compared to the attacker's chain, so it seems like the client could pick up on which blocks are valid and invalid by comparing the size of the chains.

I still don't think it would work... all you're doing in essence is relegating the consensus mechanism over to the litecoin network, which could be attacked more cheaply than Bitcoin.

[CoinHoarder]

This I disagree with though, because someone would need to attack both the Litecoin AND Bitcoin network at the same time.  

Yes, BUT the attack on Bitcoin would be much much cheaper if all you had to do was create a block
and your chain didn't have to be longer than the networks'.  

I see where you are going. This is what Mike proposed in that case:

3. Add a feature to Litecoin clients that allow Litecoin users to decide to prefer or not-prefer branches of a Bitcoin fork while one is in progress.  The default for this should always favor the Bitcoin leg with the most longevity, and should disfavor long chains that suddenly appear to replace a large amount of the known Bitcoin block chain.  The user/miner/pool-op should always have an easy way to have the final say, such as by pasting in a preformatted message either exiling or checkpointing Bitcoin blocks.

I feel like this may be able to be improved upon if a lot of people thought about it. Do you see a glaring issue in the idea? The way it was stated may not be the best way to implement it, but the idea seems like it could work.

The main chain would be quite long compared to the attacker's chain, so it seems like the client could pick up on which blocks are valid and invalid by comparing the size of the chains.

I still don't think it would work... all you're doing in essence is relegating the consensus mechanism over to the litecoin network, which could be attacked more cheaply than Bitcoin.

That's why it requires cooperation in between the Bitcoin and Litecoin development team. Bitcoin should protect Litecoin in the same way. Otherwise, you could add a 3rd coin to the chain making all coins even harder to attack.

Anyways, according to one of the most knowledgeable replies I've received thus far is that this can be done without a hard fork, and it makes it even harder to attack the Litecoin block chain in another way not mentioned in the OP:

if I remember my talks with vinced when he was implementing merge mining for namecoins, there is a unique random identifier used as input for creating new block. Vinced replaced this random number with hash for namecoins. This approach allowed creating valid merged blocks for both bitcoin and namecoin, while only namecoin had to be modified. This piece of data which was important for namecoin remained random for bitcoin as required by bitcoin specification.

Here we could use the same random piece of data, but instead of generating a random number we could use the hash of bitcoin block. From the litecoin point of view it won't be a harfork, because it will work for older litecoin clients which will view this piece of data as random number as required by litecoin specification. In fact the job of "extracting" bitcoin blockchain hashes will be a job for litecoin blockchain analysers.

So, if I'm not wrong, we can do this without a hard fork.

wow, I just realised that it would also make more difficult 51% attacks on litecoin. If someone wanted to suddenly flood the ltc blockchain with different blocks, he would need to make sure that they are in sync (time wise speaking) with bitcoin blocks.

Also, since most of litecoind modifications get merged to bitcoin, the bitcoin blockchain could similarly secure the litecoin chain using exactly the same approach. Then only a 51% attack on both blockchains simultaneously could succed. Far less likely to happen.

If my previous post is correct, then it all can be done without a hardfork!

[QuestionAuthority]

Bitcoin is in the process of becoming the mainstream alternative to classic banking and payments. The general public is confused enough about crypto currencies as it is and altcoins aren't helping that perception. I've never believed that crap about Litecoins silver to Bitcoins gold. That's like saying the USA needs to have Pesos and Dollars to pay for different items. That's total bullshit. Altcoins are pulling users away from adopting Bitcoin and more importantly using Bitcoin. They create an unnecessary confusion when the uninitiated look at Bitcoin. It already looks like a list of game money (WoW gold, Bitcoin, Linden, Litecoin, Zeevex, Doge). I have pumped and dumped my share of alts and made a tidy sum doing it. When Litecoin first came out I was mining Bitcoin on GPUs and Litecoin on the idle processors of a dozen computers. Alts can be money makers like a Ponzi can be a money maker.

I don't want to require the survival of any altcoin because Bitcoin is tied to it. I think if Bitcoins problems are addressed by the dev team it will be the survivor because it has a head start. All of the alts will die a slow death while Overstock and Expedia are still taking Bitcoin. There must be another solution to PoW.

[CoinHoarder]

I just want this idea to be given a fair chance without politics getting in the way. If it is indeed a good solution to 51% attacks, then I don't feel it should be brushed aside because of our feelings towards Bitcoin (in case of Litecoiners) or Litecoin (in case of Bitcoiners.)

The 51% attack problem is not really easy to solve otherwise it would have been done already. We need to be proactive and if there is a solution such as this that someone has already proposed and makes the least bit of sense, then I feel like we should give it more attention. I'm more interested in the technicalities of this, how it could be implemented, and whether or not it will require a hard fork, rather than people's opinion on Litecoin or Bitcoin.

As I said, this method could be used on a different coin other than Litecoin, but Litecoin is in my opinion the logical choice due to the stability of its network and Scrypt ASICs making it one of the strongest PoW ALT coins. It may be a good idea to add a 3rd link to the chain such as a PoS coin... the attacker would have to 51% Bitcoin and Litecoin, and then gain majority stake in the PoS coin. It should be made so that if one link in the chain breaks all the others will be fine. I think there are a lot of ways this could be implemented.

[jonald_fyookball]

That's why it requires cooperation in between the Bitcoin and Litecoin development team. Bitcoin should protect Litecoin in the same way. Otherwise, you could add a 3rd coin to the chain making all coins even harder to attack.
 

It's not necessarily a question of cooperation.

The problem can be reduced to logical operators: AND vs. OR.

Do you require longest chain AND a litecoin component?
or is it longest chain OR a litecoin component.

The OR solution is clearly bad, as it throws Bitcoin
security out the window, as we just discussed.

However, the AND solution might be too constraining.
If an attacker were to just hit the litecoin network,
it could prevent consensus, causing split chains or
blocks to be unsolved.