Topic: I will create a forked bitcoin chain - page 2. (Read 6922 times)

A key point for success - and the key difference from the current branch history - is that a large community are given opportunity to start at same time. The whole world actually. So the date should be announced well ahead the fork, and software be made available in good time too. Also exchanges and places who hold other peoples coins must be given time to keep track of the owners of the bitcoins at the point of the fork. (in my main paper I suggested 1st September mainly as an example date)

As one can see from this thread, there are a lot of technical question, innovation and decisions to be resolved. So the idea is still premature. But I would really like to see some experimenting take place.

The forking can't harm bitcoin in any way. If so I would have found a fatal weakness - but no. And regarding Ukigo's comment; I do not have ill intentions for bitcoin - on the contrary! I urge you to read my earlier post explaining the motivation. https://bitcointalksearch.org/topic/m.1878463

Whats the worse that can happen? They can't use this fork to steal coins can they?

Based on the comments right after yours, it looks like that attempt is successful, unfortunately.

This seems a great idea. The bitcoins are mostly controlled by early adopters now. Most people have very little of them ... so most will be willing to have a forked chain. The problem is the preparation. Since only longest chain will prevail, the new client program for it would sync with the normal chain for a while (could be a few months), when enough people using it, then at a given time it can trigger the fork, and if more people using it, it will supersede the original one and become the dominate chain. An idea worth a try.

But you all missed the TRUE OP's goal :
to confuse/delude(or defraud ?) as many Bitcoin users as he/she/CIA can...

Before anything happens can we get a date for when the fork will be?

I want to move all my Bitcoins to a wallet I control before the fork. (Some of my coins sit in exchanges)

These steps aren't necessary. You could prune everything down into one block with just txouts and use that as the genesis block itself. Sort of starting with a clean slate but with coins being currently where they are. No bitcoin client is going to accept this fork, so you may as well put some effort into making LNC less of a hassle.

Nope, for two reasons.  Firstly, only if the block is of a greater height than any block the client already knows about will the client then relay it.   Secondly, the amount of coin generated (200 BTC) would fail the block validation logic (as it exceeds 25 BTC at these block numbers), so the Bitcoin-Qt/bitcoind client would reject the block and, of course, not relay it.

Guys come to freenode #noobcoin lab Plenty of discussions there and ready to swap ideas

That makes sense. In fact, I just read that in the transaction validation logic last night. Duh!
But they do relay new block announcements. Even if they are off the current chain. Right?


So option (2) requires BitCoin developer buy-in even for a plausible test.
I'm not an advocate of that path. I just mentioned it because I presume that is what wingding was initially thinking.

1. Download source
2. Change the mining parameters
3. Checkpoint a particular forking block
4. Compile, run and "Away we go!"

Could do option (1) by:
1a Download source
1b Download block chain
2a Change the mining parameters
2b Change the port
2c Tweak the genesis to change its hash
2d Re-hash all the other blocks at trivial difficulty
3. Checkpoint a particular forking block
4. Compile, run and "Away we go!"

At least that would get to a stable TestNet configuration to mess with.

Now I'm not Pollyanna. I don't expect this concept to be popular despite the free coins.
Without significant mixed-mining support people are going to treat this chain like Indiana John's whip!

I just want to compile the client and dink with it for practice. I've got my own Alt-Coin ideas. I just need a simple shared goal as motivation to get started.

Nope, if the transaction includes any INPUTs from a block post-fork, that transaction would be invalid on the Bitcoin blockchain side and those nodes would not relay the transaction. 


If the fork is trying to use the same port (8333) and it gained a following (i.e., a lot of nodes using it) then likely the Bitcoin-Qt/bitcoind client would treat these as harmful and possibly require an update to address this thread (e.g., have the client disconnect early after some threshold of invalid transactions is received).

Have you already started work on this? Or is this your pre-project brainstorming?

WARNING: I am not an expert on this but I have a software engineering background and reasonable familiarity with the block chain and transaction graph data structures.

There are two ways to approach the problem.

1. Create a new LinearCoin P2P network entirely disconnected from the existing BitCoin P2P nodes.

    This would require copying the entire BitCoin block chain to your new nodes before they could start relaying
    transactions independent of the BitCoin P2P network. Theoretically, this keeps LinearCoin transactions from
    spending BitCoins. HOWEVER, new LinearCoin transactions accessing these pre-fork blocks would be bitwise
    copies of transactions that COULD spend on the BitCoin Chain. All it would take is for ANYONE to copy it and
    submit it to the BitCoin network. You have to presume some malicious node WOULD.

    Merged mining is theoretically possible in this case. Search for NameCoin they invented the concept.
    Merged mining does NOT imply that LinearCoin block creation would be synchronized with BitCoin nor
    that its difficulty be the same. It doesn't come for free though. You have to convince existing BitCoin
    miners to support your chain as well. If they saw LinearCoins as valuable, supporting merged mining
    would be as easy for them as supporting NameCoin.

2. Attempt to "peacefully" use the existing BitCoin P2P nodes for relaying transactions.

    In this case your fork might be able to coexist on nodes along side the bitcoin fork. I think nodes do this by
    default. However, long term support would require BUY-IN from the existing BitCoin developers because at
    some point they will lock-in a block CHECKPOINT outside your fork. At that point BitCoin nodes would likely
    stop relaying your transactions.

    Mixed mining is this case should be even easier. However, again, it requires BUY-IN from the BitCoin developers.

The transactions on the new chain must not be valid on the old chain, and vice versa. So the old coins present in the new chain can only be spent as LNC. The two chains should then be independent after the split (or am I wrong here?)

I think merged mining should not be possible, because it would be a strength to maintain a relation by mining cost and value of coin. As suggested in Etlase's signature. I think merged mining would disturb that relation.

Yep, and if LNC and BTC addresses will have the same version, we'll know that Bitcoin
 is under attack...

The solution to fix accidentally spending on both forks is pretty simple: use an incompatible address in LNC. Existing txouts will be acceptable as inputs, but new outputs can only be sent to LNC addresses.

Keep in mind anyone holding money for someone else (mtgox) is now wholly entitled to that money on your chain.

You just don't care, as long as it's a new coin ? These crapcoins only distract on what we should be focussing on : actual innovation.

It's still a pretty big quirk but I guess you could fix the client to warn about and correct the issue. You pointed out the fix...


But I think it's easier than that. You just need to send all of your coins to yourself first. Doesn't matter which chain you do that on. That will split all your coins into their appropriate forks. From there you can spend them independently. The client could do this automatically for you the first time you use it. That would destroy all your coin age and maybe cost some fees.


Fortunately, even if that happened "lost" LinearCoins coins would still be spendable. The BitCoiner would just have to come looking for them. Theoretically they still have valid keys.

Yep, you need purposefully spend both sets of coins to different addresses before a replay happens on the other network. I think I'd generate 2 new keypools too and redo my vanity if I started using it. The problem is that if you are not aware of it you are sending your alt-chain value to uncontroled addresses in an alternate universe, so the number of lost coins will be HUGE unless a large portion of the bitcoin ecosystem takes action at or around launch of the fork.

Congratulations, you have figured out how to premine to pure hoarders and insiders only. Any addresses that do transactions between launch and alt-coin discovery are at risk of losing it all in the new chain.

Actually, he has a pretty solid point. I missed it on first read.

Any spendable BitCoins that existed before the form are spendable LinearCoins on the new fork. Stephen is pointing out that spending the LinearCoins from address "ABC..." creates a transaction that is bitwise identical to the one needed to spend the BitCoins at address "ABC..."

Is that an intended feature or an issue?

It means that your ostensibly pre-distributed LinearCoins exist in a strange state. If I send my BTC to Fred, my LNC goes with it. If I send my LNC to Fred, my BTC goes with it. On the other hand, Fred receiving the coins post fork WILL get two independent coins to spend. That's twisted