Topic: Litecoiners: Idea to make Litecoin importance skyrocket in Bitcoin ecosystem - page 5. (Read 13385 times)

It would have had no effect.  It sits in standby until the Bitcoin community has an emergency to which there are very few good competing solutions.  The March fork was easily resolved with a Bitcoin-only option that was clearly going to work all the way from the beginning, and using a Litecoin reference as a fallback wouldn't have been seen as necessary or useful.

This is meant to be a remedy for a deliberate 51% attack to the Bitcoin blockchain... one where you can't trust SHA256 blocks because it's clear somebody malicious has acquired an unexpected ability to do lots of SHA256 hashing.

Casascius,

How would this IDEA have worked in theory in the most recent forking of bitcoin that happened back in March?

Are you kidding me? This is an awesome idea!

Just like that, Bitcoin is now somewhat protected by SHA-256 and Scrypt, while Litecoin is now given additional value and keep those GPU/CPU around to protect the blockchain. Indeed, it is a wonderful marriage between those two coins.

So if there are very large changes to the bitcoin blockchain (in a short period of time), deny the new blocks as invalid? Interesting...

Time requirements as well as size of change in the blockchain would need to be specified. This may need quite a bit of testing to determine what a valid set of new blocks are and how far back in the bitcoin blockchain a fork could be allowed to rewrite if someone were to come online with a large hash rate.

Maybe something like anything above 10 previous bitcoin blocks changed suddenly would consitute a denial of validity of a forked chain?

This will indeed cap the amount of new hashing power (as difficulty increases) that any one entity could put online to mine bitcoins at any one time.

I guess also using old time stamps of created blocks would also be a way of determining which is a "valid" chain that forked recently.

Very interesting Casascius.

I like the idea. Appears now Litecoin may actually have another purpose in addition to a hedge against bitcoin.

Looking forward to what comes out of this.

1. The Litecoin client would have to connect to port 8333 of at least one node of the bitcoin network but probably wouldn't need to validate the bitcoin transactions.  Rather, it need merely listen for blocks and validate the proof-of-work, possibly saving the 80-byte headers and nothing more to aid in this, and throw out any other incoming information.

2. Forks shouldn't matter as this information is purely informational for the benefit of bitcoin... or at least, I don't understand how a fork could cause a problem.  A fork gets resolved the same way it already does.  The criteria of what constitutes valid Bitcoin data in Litecoin's new "bitcoin" field depends only on the Litecoin block before it and the current hash of the newest Bitcoin block.  Litecoin forks are invisible to the evaluation of this, and so long as a Litecoin block satisfies the requirements with respect to the block that came before it, forks shouldn't get in the way.  The only decision making Litecoin ought to do with respect to the Bitcoin data is to perhaps retard the propagation of a newly created Litecoin block that clearly contains very stale Bitcoin data.

If Bitcoin were to temporarily fork and the Litecoin block chain recorded the hash of an orphaned Bitcoin block, this would be OK, ignored, and would not invalidate the Litecoin block.  However, that block would be more likely to be thrown out by the Litecoin network since many Litecoin nodes might never hear about the orphan and won't be able to validate the Litecoin block.  (The behavior could use some more refinement to cover all of the what-if's, but thus far, I just wanted to throw out the general idea of having Litecoin be a validator/observer for Bitcoin as a savior case of a SHA256 51% attack, which sounds like an enthusiastically received idea in and of itself, regardless of there being things to iron out)

Casascius, I think this is a very interesting idea. I've always thought of Litecoin as a complimentary coin to Bitcoin and I am definitely interested in making a change to Litecoin that is beneficial to Bitcoin.

There are a few things that need to be worked out though.

1) Does this means that each Litecoin client/miner has to be both on the Bitcoin network and the Litecoin network in order for it to verify blocks or create blocks with the latest bitcoin block hash? Or maybe only the miners have to be on the Bitcoin block chain?

2) How do we handle forks? What if the Litecoin blocks have a eventually losing fork in the block chain? How do we then switch to the winning chain?

Neat concept.  Anything which favors a larger crypto-economy over a single chain is generally good.

If anyone is looking for a physical litecoin in the meantime, you can get something like it here:  https://www.bitmit.net/en/item/21037-3d-printed-nfc-enabled-litecoin-simulacra

Count me in!!!

This general idea of yours for sync'ing the Bitcoin block header hashes into the Litecoin blocks is an interesting suggestion.

I failed to understand why would we need "a repeat of the hash", according to your suggestion isn't it true that the next Litecoin L_0 block will either include the next-needed Bitcoin block B_0 hash or the last Litecoin block L_1 hash, so after L_0 was generated, the following Litecoin block should include either the header hash of L_0 or the next-needed Bitcoin block, so there are no repetitions? Actually, wouldn't it be better to require that the next Litecoin block must always include the header hash of the previous Litecoin block, and optionally also to include the next-needed Bitcoin block header hash?

What you said about "any leg of the chain" is a bit unclear, nodes aren't required to keep competing legs (a.k.a. branches). I think that what you meant is that if the node sees that its preferred Bitcoin branch disagrees with the branch continuation of Bitcoin hashes inside the Litecoin blocks, then it should still accept these Litecoin blocks, as long as that different Bitcoin branch is valid (even though it isn't the longest Bitcoin branch according to what the node gathered while listening on the Bitcoin network) ?

About allowing users to decide to prefer or not-prefer branches, I've written before in another context that I think that it's a terrible idea:

Interesting concept Mike, "marriage-mining"  imo

This would make botnet operators that mine litecoins happier and bitcoiners will benefit from it too, so it's a win-win situation.

I guess that comes down to if the majority are in favour a voting system of proportional representation or first past the post... if you get my meaning...

I personally like the idea though. Can anyone think of ways we could make the implementation even simpler whilst maintaining similar functionality?

Exactly.

So if I've got this right your suggesting another axis of selection for bitcoin branches above the >50% hash rate? And that selection factor would be the ability for litecoin mining clients on the litecoin chain to vote which one they favoured; where hopefully litecoin could not suffer from a >50% exploit at the same time as it uses a different hashing algorithm to bitcoin?

I'd definitely buy physical litecoins off of you too mike!

Quick rant: I have always viewed Litecoin as a detraction from Bitcoin and have refused to make mass quantities of physical Litecoins as a result.  I have viewed Litecoin as nothing more than a hedge against Bitcoin seeing a 51% attack due to choice of SHA256 as an algorithm.

But:  I believe I have thought of an idea that would make Litecoin far more important and relevant in the Bitcoin/cryptocurrency ecosystem, by being as ready in wait as possible in case Bitcoin really does experience a 51% attack.

In a nutshell, I view a Bitcoin 51% attack as eventually possible, for one reason:  ASIC production efficiency scales far more than linearly with the amount of money an actor is willing to put into it; a bad actor with $1 billion to 51%-attack Bitcoin with its own custom ASICs will be far more than ten times as effective than ten bad actors with $100 million.

Anyway: here is the idea:  Add a mandatory merge-mining feature to Litecoin so that it is always "merge-mining" Bitcoins, just for pretend, in hopes that one day Bitcoin will have the option of "let's subscribe to the Litecoin chain" (as a secondary means of block validation) as a way to resolve a future 51% attack on Bitcoin's SHA256-based chain.

Here is sort of how it would work:

1. Add a new requirement to the Litecoin chain such that a valid Litecoin block must contain either a record of the most recent Bitcoin block header hash, or a repeat of the hash found in the prior Litecoin block (with a limit of repetitions).  Litecoin blocks that contain outdated Bitcoin intelligence should be disfavored by nodes capable of detecting that.  Further impose the requirement that Bitcoin block headers must be represented contiguously in the Litecoin chain - Bitcoin blocks cannot be skipped (which shouldn't be a problem, when Litecoin blocks happen 4x as often as Bitcoin)
2. 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.
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.

Anticipated benefits:

1. Bitcoin users would have a ready made remedy to a 51% attack that they can switch to:  Bitcoin users can simply add the requirement that if a Bitcoin block header hash makes it into the Litecoin chain, that its proof of work should be given a bonus.  Litecoin community could create and maintain pulls to the Satoshi client that cause it to subscribe to the Litecoin chain and incorporate it as intelligence toward block validation and resolving block chain forks.
2.  Bitcoin would have an easy way to add an emergency upper bound to block creation, just in case an enormous amount of power suddenly appeared.  By turning on an optional must-appear-in-Litecoin requirement, the Bitcoin community could switch on an upper bound of 1 block per 2.5 minutes if it was deemed necessary.
3. Litecoin would be seen as far more important than a wannabe bitcoin knockoff without added value by those who see it that way.
4. Bitcoin's blockchain would be re-democratized to CPU/GPU users without forcing the Bitcoin community to switch to scrypt, they'd have more decentralized influence on bitcoin than those with the means to buy/make ASICs
5. The legitimacy of Litecoins would increase greatly - people would see the value of Litecoins in their role of protecting Bitcoin, and would potentially vote for the longevity of Litecoin by offering to accept LTC for goods and services, thereby increasing their value.
6. I'd start making Casascius Litecoins if you guys did this and did it well.

I'd call the concept "marriage-mining".  By doing something like this, LTC gives a nod to BTC's importance while adding synergistic value to BTC that LTC can benefit from by association.