I will create a forked bitcoin chain

[Stephen Gornick]

Seriously dude?  Thats mondo easy.  take all the adjust values for unspent outputs and write them into the genesis block to the address they belong as coinbase txs.

I was interpreting wingding's statement as describing how coins issued prior to the fork would still be spendable on the inflatacoin side of the fork ... that they wouldn't be touched (i.e., "harmed").    But my assertion is that any spending of a "pure" coin issued pre-fork is a valid transaction on both sides thus any spending on the inflatacoin side is harmful to the holder of the coin.

A pure coin is one that has no taint from the coins issues after the fork, and thus would be a valid spend transaction on the Bitcoin blockchain side as well.

Now I suppose you could ensure that the inflatacoin client included in every spend transaction some taint in the INPUTs so that the transactions would only be valid on the inflatacoin side.  I still personally wouldn't use any coins with that client until they've been fully spent on the Bitcoin blockchain side, but after that I might milk the inflatacoin fork for whatever I could get from it, sure.

[1715651217]

1715651217

[wingding]

Seriously dude?  Thats mondo easy.  take all the adjust values for unspent outputs and write them into the genesis block to the address they belong as coinbase txs.

I was interpreting wingding's statement as describing how coins issued prior to the fork would still be spendable on the inflatacoin side of the fork ... that they wouldn't be touched (i.e., "harmed").    But my assertion is that any spending of a "pure" coin issued pre-fork is a valid transaction on both sides thus any spending on the inflatacoin side is harmful to the holder of the coin.

A pure coin is one that has no taint from the coins issues after the fork, and thus would be a valid spend transaction on the Bitcoin blockchain side as well.

Now I suppose you could ensure that the inflatacoin client included in every spend transaction some taint in the INPUTs so that the transactions would only be valid on the inflatacoin side.  I still personally wouldn't use any coins with that client until they've been fully spent on the Bitcoin blockchain side, but after that I might milk the inflatacoin fork for whatever I could get from it, sure.

Yes you understood me right, I dont have to create any genesis block. All oldcoins get included by beeing there. How in the world do you think I could influence the transaction in the old chain? Thats not possible. Appearantly your term inflatacoin suggest that this new coins would be subject to inflation. In that part you are wrong, and I believe you know it. Bitcoin had even larger rate of increase in its beginning. Remember that word inflation refers to value of the asset, not the amount.

[Cheshyr]

Random thought; probably nonsense...

Couldn't someone fork one of these AltCoins while it's still early, leave everything the same, but adjust the difficult to a something stupid low, and solo mine it?  Wouldn't that fork the chain at the genesis block, essentially?

[Walter Rothbard]

Remember that word inflation refers to value of the asset, not the amount.

I hate to tell you this, but no, it doesn't.

[Red]

Yes you understood me right, I dont have to create any genesis block. All oldcoins get included by beeing there.

Hi wingding! Thanks for introducing yourself in my thread. I read both of your threads and agree with your "why" logic. I have to admit this is one of the more interesting approaches so far. Specifically forking off the existing chain.

How far along are you? I might like to help out.

Technically, it doesn't seem particularly hard. Are you going to set it up to use merged mining? That seems logical since you are giving the people already mining bitcoin free coins.

I think the word "forked" in the topic is confusing people. It makes it seem like you are trying to create duplicate BitCoins. I'm pretty confident that is not your goal. It might be useful to adjust your description to one that parallels what other AltCoins have done.

I will create a forked chain new coin "LinearCoin" to accommodate broad adaptation.

The only major change from BitCoin is:

Reward of 200 BTC per block for each new block - (never changed)

• "LinearCoin" will have an 11 million+ pre-mine with all coins pre-distributed to existing BitCoin owners.
• The chain will produce 10.5 million coins/year (which is far from enough to cause inflation)
• The clients (incl source) running the new fork will be made available well ahead of the fork

You should also make it clear that LinearCoins are not BitCoins and will never operate as interchangeable (value equivalents) with merchants or existing exchanges. Might also make it clear that BTC to LnC trading will have its own market determined exchange rate.

Just a suggestion.

[Red]

But my assertion is that any spending of a "pure" coin issued pre-fork is a valid transaction on both sides thus any spending on the inflatacoin side is harmful to the holder of the coin.

How in the world do you think I could influence the transaction in the old chain? Thats not possible.

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

[scrybe]

But my assertion is that any spending of a "pure" coin issued pre-fork is a valid transaction on both sides thus any spending on the inflatacoin side is harmful to the holder of the coin.

How in the world do you think I could influence the transaction in the old chain? Thats not possible.

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

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.

[Red]

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...

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.

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.

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.

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.

[Joerii]

I will create a forked chain of bitcoin to accomdate for broad adaptation.

The only major change from the old chain is:

Reward of 200 BTC per block for each new block - (never changed)

• The chain will produce 10.5 million coins/year (which is far from enough to cause inflation)
• The clients (incl source) running the new fork will be made available well ahead of the fork
• All bitcoins created before the fork will by nature be contained in the new chain

Count me in. Any deadlines set?

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.

[Etlase2]

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.

[wingding]

But my assertion is that any spending of a "pure" coin issued pre-fork is a valid transaction on both sides thus any spending on the inflatacoin side is harmful to the holder of the coin.

How in the world do you think I could influence the transaction in the old chain? Thats not possible.

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

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.

[Red]

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.

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.

[Stephen Gornick]

I think nodes do this by default

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. 

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.

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).

[Red]

I think nodes do this by default

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.  

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?

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.

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).

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.

[alex_fun]

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

[Stephen Gornick]

But they do relay new block announcements. Even if they are off the current chain. Right?

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.

[Etlase2]

2d Re-hash all the other blocks at trivial difficulty
3. Checkpoint a particular forking block

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.

[drawingthesun]

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)

[js2082]

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.

[Stephen Gornick]

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

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